Налаштування реплікації баз даних 1С-Бітрікс

Налаштування реплікації баз даних 1С-Бітрікс

MySQL-реплікація для 1С-Бітрікс вирішує три завдання: 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 для 1С-Бітрікс, де зустрічаються недетерміновані функції в запитах (NOW(), RAND()).

binlog_row_image = MINIMAL — у binlog записуються лише змінені колонки, а не весь рядок. Зменшує обсяг binlog на 60–80% для широких таблиць 1С-Бітрікс.

Створюємо користувача реплікації:

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

Підключення 1С-Бітрікс до репліки

1С-Бітрікс не має вбудованого автоматичного 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: просуваємо репліку в мастер, перенаправляємо 1С-Бітрікс.

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

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