Репликация базы данных

Репликация MySQL master-slave — основа масштабирования базы данных в веб-кластере 1С-Битрикс. Она распределяет нагрузку чтения между репликами и повышает отказоустойчивость. Разберём настройку, маршрутизацию запросов и типичные подводные камни.

Принцип работы репликации

В схеме master-slave один сервер (мастер) принимает все изменяющие запросы, записывает их в бинарный лог, а реплики (slave) проигрывают этот лог у себя. Модуль cluster знает о репликах и автоматически направляет на них запросы SELECT, оставляя запись на мастере.

Это даёт два эффекта: чтения масштабируются горизонтально (добавили реплику — увеличили пропускную способность на чтение), а мастер разгружается. Большинство запросов на типовом магазине — именно чтения, поэтому выигрыш заметный.

Настройка MySQL

Сначала настраивается сама репликация на уровне MySQL, до подключения в Битрикс. На мастере в my.cnf:

[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = MIXED

На реплике задаётся уникальный server-id и запускается репликация с указанием координат бинлога мастера:

CHANGE MASTER TO MASTER_HOST='10.0.0.1',
  MASTER_USER='repl', MASTER_PASSWORD='***',
  MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;
START SLAVE;

Состояние проверяется командой SHOW SLAVE STATUS\G — интересуют Slave_IO_Running, Slave_SQL_Running (оба Yes) и Seconds_Behind_Master.

Подключение реплики в Битрикс

Готовую реплику подключают в административной панели: Настройки → Веб-кластер → Репликация БД → Добавить сервер. Указывается хост, доступы и процент нагрузки чтения, который ядро будет отправлять на этот узел.

• Битрикс проверит соединение и корректность работы репликации при добавлении.
• Процент чтения можно менять на лету — например, снизить до 0 перед обслуживанием реплики.
• Реплику можно временно отключить, не удаляя из конфигурации.

После подключения ядро само балансирует SELECT-запросы, разработчику не нужно менять прикладной код.

Управление маршрутизацией из кода

Иногда автоматической маршрутизации недостаточно. После записи данные должны быть прочитаны гарантированно свежими, а реплика может отставать. Для этого есть управление на мастер:

global $DB;
$DB->StartUsingMasterOnly(); // все SELECT идут на мастер
// ... критичная логика чтения свежих данных ...
$DB->StopUsingMasterOnly();

Механизм полезен в сценариях «записал заказ — тут же прочитал его для формирования чека». По умолчанию Битрикс и сам держит соединение на мастере в рамках запроса после операций записи, но для сложной логики явное управление надёжнее.

Отставание реплик и консистентность

Асинхронная репликация означает, что реплика может отдавать данные с задержкой. Это нормально, но требует внимания:

Отказ мастера и переключение

Штатная репликация Битрикс масштабирует чтения, но автоматического переключения (failover) при падении мастера в ней нет — запись остановится. Для отказоустойчивости записи применяют внешние решения:

1. MHA / Orchestrator — автоматическое продвижение реплики в мастер.
2. Galera Cluster / Percona XtraDB Cluster — синхронная мультимастер-репликация вместо классической master-slave.
3. Ручное продвижение реплики и переключение доступов при аварии по регламенту.

Выбор зависит от требований к RPO/RTO. Для многих проектов достаточно быстрого ручного продвижения реплики плюс мониторинг.

Итог

Репликация master-slave в 1С-Битрикс распределяет чтения между репликами и разгружает мастер, масштабируя базу горизонтально. Настройка идёт в два шага: репликация на уровне MySQL и подключение узла в модуле cluster. Главное — учитывать асинхронность и контролировать отставание, а для отказоустойчивости записи подключать внешний failover.

Мы настраиваем репликацию и балансировку БД для highload-проектов на Битрикс: от схемы реплик и оптимизации запросов до автоматического failover и мониторинга отставания. Поможем убрать узкое место в базе без переписывания прикладного кода.