Настройка репликации баз данных 1С-Битрикс

Настройка репликации баз данных 1С-Битрикс

MySQL-репликация для Битрикс решает три задачи: read scaling (SELECT на реплики), резервное копирование без нагрузки на мастер (dump с реплики), и быстрый failover при аварии мастера. Без репликации база данных — единственная точка отказа всего проекта.

Настройка мастера

/etc/mysql/conf.d/master.cnf:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
binlog_row_image = MINIMAL
expire_logs_days = 7
max_binlog_size = 100M

# Для GTID-репликации (рекомендуется)
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON

# Безопасность данных
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

binlog_format = ROW — построчная репликация. Надёжнее чем STATEMENT для Битрикс, где встречаются недетерминированные функции в запросах (NOW(), RAND()).

binlog_row_image = MINIMAL — в binlog записываются только изменённые колонки, не весь ряд. Уменьшает объём binlog на 60–80% для широких таблиц Битрикс.

Создаём пользователя репликации:

CREATE USER 'replicator'@'10.0.0.%' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.0.0.%';
FLUSH PRIVILEGES;

Настройка реплики

/etc/mysql/conf.d/replica.cnf:

[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log  # для цепочки репликации
log_slave_updates = ON

gtid_mode = ON
enforce_gtid_consistency = ON

# Реплика только на чтение
read_only = ON
super_read_only = ON

# Параллельная репликация (MySQL 5.7+)
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4

super_read_only = ON — запрещает запись даже пользователям с SUPER-привилегией. Предотвращает случайную запись напрямую в реплику, что сломает репликацию.

Инициализация репликации с GTID:

-- Снимаем dump мастера
mysqldump --single-transaction --master-data=2 --gtid \
    -u root -p bitrix > /tmp/bitrix_dump.sql

-- На реплике восстанавливаем и запускаем
mysql -u root -p bitrix < /tmp/bitrix_dump.sql

-- Настраиваем источник репликации
CHANGE MASTER TO
    MASTER_HOST = '10.0.0.10',
    MASTER_USER = 'replicator',
    MASTER_PASSWORD = 'strong_password',
    MASTER_AUTO_POSITION = 1;  -- GTID: позиция определяется автоматически

START SLAVE;
SHOW SLAVE STATUS\G

В SHOW SLAVE STATUS смотрим:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: 0

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

Битрикс не имеет встроенного автоматического read/write split. Настраиваем через модуль кластера или вручную:

// /bitrix/.settings.php
'connections' => [
    'value' => [
        'default' => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => '10.0.0.10',  // мастер
            'database'  => 'bitrix',
            'login'     => 'bitrix',
            'password'  => 'pass',
        ],
        'replica' => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => '10.0.0.11',  // реплика
            'database'  => 'bitrix',
            'login'     => 'bitrix_ro',
            'password'  => 'pass_ro',
            'options'   => ['slave' => true],
        ],
    ],
],

Компоненты каталога, поиска и листинга направляют SELECT на реплику. Корзина, заказы, авторизация — всегда на мастер.

Мониторинг репликации

-- Задержка репликации
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: задержка в секундах

-- Ошибки репликации
SELECT * FROM performance_schema.replication_applier_status_by_worker;

При Seconds_Behind_Master > 30 пользователи могут видеть устаревшие данные из реплики. Причины: тяжёлые транзакции на мастере, недостаточно параллельных воркеров на реплике, I/O узкое место.

# Непрерывный мониторинг задержки
watch -n5 'mysql -u monitor -ppass -e "SHOW SLAVE STATUS\G" 2>/dev/null | grep "Seconds_Behind"'

Failover при аварии мастера

Ручной failover: промоутируем реплику в мастер, перенаправляем Битрикс.

-- На реплике
STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

Меняем host в .settings.php на IP новой мастер-ноды. Автоматический failover через Orchestrator или ProxySQL — для критичных проектов без допустимого времени простоя.