Настройка репликации Master-Slave в Bitrix

upd Написал новую статью по более простой настройке репликации

Дано:

Виртуальная машина №1 (будущий мастер) с IP-адресом 192.168.10.175
Виртуальная машина №2 (будущий слейв) с IP-адресом 192.168.10.176 (по совместительству также клон 1 виртуалки для тестового стенда, в продакшн так лучше не делать)

Рассмотрены будут два случая: когда БД лежит на отдельном сервере и когда вместе с nginx и apache на одном.

Версия и тип БД на обоих серверах: MySQL 5.7 Percona
Имя БД: sitemanager (дефолт битрикса)
ОС: Centos 7.4

Задача:

Настроить репликацию Master-Slave в bitrix через модуль веб-кластер, не прибегая к скрипту /root/menu.sh

Поехали! Правка конфигурационных файлов

Начать лучше с конфигурационного файла БД на обоих серверах. Тут есть несколько моментов:

Кодировка. На тестовом стенде возникала проблема при проверке системы к готовности репликации, связанная с кодировкой БД и таблиц. По-хорошему лучше разобраться, как работает кодировка и представления в MySQL. Но в случае, если подобное возникнет, а разбираться не хочется, то решается так (на обоих серверах – мастере и слейве):

[mysqld]
   character-set-server = utf8
   collation-server = utf8_unicode_ci
   init-connect = "SET NAMES utf8 COLLATE utf8_unicode_ci"
   skip-character-set-client-handshake # помогло, когда кодировка упорно не захотела вставать на место. Игнорирует клиентскую кодировку и юзает ту, которая на сервере.
[client]
    default-character-set = utf8 

А также конвертировать всю базу в случае иных проблем:

alter database sitemanager character set utf8 collate utf8_unicode_ci;

Параметры репликации на мастере. На этом моменте будет единственное отличие конфига мастера от слейва:

server-id = 1

# путь к бинарному логу
log-bin=mysql-bin # путь указывать не обязательно

# название Вашей базы данных, которая будет реплицироваться
binlog_do_db = sitemanager # binlog_do_db - для мастера

Если директория /var/log/mysql/ указана в конфиге, то она должна физически существовать, а владелец её должен быть mysql:

Теперь необходимо поправить конфиг слейва:

# ID Слейва, удобно выбирать следующим числом после Мастера
server-id = 2

# Путь к relay логу
relay-log = /var/log/mysql/mysql-relay-bin.log

# База данных для репликации
replicate-do-db = sitemanager # replicate-do-db - для слейва

Забегая немного вперед, можно сразу для удобства поправить параметр в MySQL на обоих серверах:

innodb_flush_log_at_trx_commit = 1 # вместо 2

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

rm -rf /var/lib/mysql/auto.cnf

После этого требуется проверка на правильность, на обоих серверах ребут:

systemctl restart mysql

В случае ошибок при старте, проверить права на все директории, которые указаны в конфиге. А также не забывать посматривать в лог. И подключить его, если он ещё не настроен:

log_error=/var/log/mysql/mysql_error.log

Время щелкать мышкой в битриксе

После развертывания дефолтного сайта (ну, или на уже имеющемся), необходимо установить модуль Веб-кластер. Для этого:

• в разделе обновлений принять лиц. соглашение (если установка новая);
• выбрать среди обновлений модуль веб-кластер, остальные галки снять за ненадобностью;
• найти Веб-кластер и установить его в разделе “Модули”.

Появится новый пункт, как на скриншоте ниже:

Осталось нажать “Добавить slave базу данных” из раздела Репликация модуля Веб-кластер.

И тут возникает мастер проверки:

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

На имеющемся сайте возникает вероятно одна проблема:

Выполните запрос: GRANT REPLICATION CLIENT on *.* to ‘bitrix0’@’%’;

Выполняем и… ничего не меняется, битрикс снова ругается.

Проблема кроется в правах внутри MySQL. По умолчанию, при развертывании битры через скрипт bitrix-env.sh, БД и веб-сервер на одном хосте, соответствено, и учетка для локального хоста и используется. А согласно правилам приоретности в MySQL, берётся та учетка, где наиболее явно указаны привилегии: имя и с какого хоста разрешено подключение. Для понимания, дефолтом в таблице (на мастере) так:

mysql> select user,host,db from mysql.db;
+---------------+-----------+--------------------+
| user          | host      | db                 |
+---------------+-----------+--------------------+
| mysql.session | localhost | performance_schema |
| bitrix0       | localhost | sitemanager        |
| mysql.sys     | localhost | sys                |
+---------------+-----------+--------------------+

mysql> select user,host from mysql.user;
+---------------+-----------+
| user          | host      |
+---------------+-----------+
| bitrix0       | localhost |
| mysql.session | localhost |
| mysql.sys     | localhost |
| root          | localhost |
+---------------+-----------+

И поэтому при добавлении прав для учетки bitrix0’@’%’ мастер не пускает на следующий шаг.

Решено – надо менять данные в таблице с MySQL (на мастере и слейве):

UPDATE mysql.user SET host='%' where user='bitrix0';
UPDATE mysql.db SET host='%' where user='bitrix0';

Теперь необходимо, чтобы изменения вступили в силу:

 flush privileges;

В случае, если слейв – копия мастера, то там всё тоже самое нужно по аналогии изменить в системных таблицах БД с локалхоста на любой хост. Если же отдельная база (не клон), то создать юзера с изначально правильными данными для подключения (не забыв указать его пароль, как на Мастере) + создать пустую базу sitemanager (можно и сразу провести раздамп в неё с мастера для ускорения репликации в будущем)

Ситуация при использовании отдельного сервера с мастер БД и слейв БД.

На мастере должен быть юзер:

• bitrix0@192.168.10.175 с доступом к базе sitemanager и паролем из dbconn.php # доступ с веб-ноды
• bitrix0@192.168.10.176 с доступом к базе sitemanager и паролем из dbconn.php # доступ со слейва

На слейве должен быть юзер:

• bitrix0@192.168.10.175 с доступом к базе sitemanager и паролем из dbconn.php # доступ с веб-ноды
• bitrix0@192.168.10.177 с доступом к базе sitemanager и паролем из dbconn.php # доступ с мастера

А права для мастера следующие:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'192.168.10.175';

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'192.168.10.176';
FLUSH PRIVILEGES;

Для слейва:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'192.168.10.175';

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'192.168.10.17';
FLUSH PRIVILEGES;

После того, как проверка успешно пройдена, можно переходить к следующему шагу мастера:

Первое поле содержит IP-адрес слейва + дефолтный порт.

Второе поле – учетная запись для подключения, причем пользователь и пароль из файла dbconn.php и .settings. Это было сделано с целью упрощения администрирования и чтобы не возникало путаницы из-за различного кол-ва учёток – так рекомендует сам битрикс.

Третье поле – IP-адрес БД Мастера (не локалхост, обратите внимание) и дефолтный порт.

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

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'%'

А на слейве, при условии, что база sitemanager уже создана, есть пользователь bitrix0@’%’ с паролем из dbconn.php (как и в мастере), требуются аналогичные привилегии:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'bitrix0'@'%'

Запрос может не сработать и выдать ошибку Incorrect usage of DB GRANT and GLOBAL PRIVILEGES, если указать конкретную БД, поэтому применяется конструкция *.*

После этого нужно обновить привилегии в БД:

flush privileges;

И убедиться, что фаервол в ОС не мешает для подключения по порту 3306 двух серверов. Для упрощения, его можно просто отключить (но в боевом окружении лучше разрешить порт, а не отключать):

systemctl stop firewalld && systemctl disable firewalld

Финал уже близок

Теперь самое время нажать Далее, мастер проверит, что все права на месте:

Снова Далее, название подключения и кнопка Готово:

Появился слейв, осталось его активировать (начать использовать):

Снова появляется мастер настройки, проходит проверка таблиц на слейве:

После инициализации, таблицы начнут копироваться на слейв, по окончании осталось нажать Готово – начался процесс репликации!

На боевом проекте с объемом базы в 27 Гб подключение слейва с использованием варианта, описанного в данной статье, было очень долго, более 4+ часов . В таком случае имеет смысл использовать другой способ репликации, т.к. на период синхронизации, публичная часть битрикса будет закрыта и недоступна, что не всегда допустимо долгое время.

Описанный способ подойдет для малых объемов БД или когда простой не критичен.

В результате будет следующее окно:

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

PS Также можно использовать репликацию на основе GTID, почитать, что это, можно в оф. документации. А для работы в конфиг серверов надо прописать:

gtid_mode=ON
enforce-gtid-consistency=true

Переключение Slave -> Master

В случае, если мастер выходит из строя, или, например, требует обслуживания, используемый слейв можно использовать в качестве мастера. Подразумевается, что запись в текущую базу остановлена (средствами веб-сервера ограничен доступ или на уровне приложения) на время проведение работ. Алгоритм следующий:

Тормозим репликацию:

STOP SLAVE IO_THREAD;

В конфиг будущего мастера добавить ведение бинарного лога:

log-bin=/var/lib/mysql/mysql-bin
systemctl restart mysql

Проверка значений, должны быть следующие:

mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+

mysql> SHOW VARIABLES LIKE'log_slave_updates'; 
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| log_slave_updates | OFF   |
+-------------------+-------+

Полностью стопорим слейв и очищаем бинлог нового мастера:

STOP SLAVE; 
RESET MASTER;

Перед сменой мастера нужно выполнить команду:

SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |    10942 | sitemanager  |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

Здесь интересует значение полей Position и File. После для включения мастера осталось выполнить:

CHANGE MASTER TO MASTER_HOST = "192.168.10.176", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 10942;

И поменять главную базу в конфигах битрикса.

Заключение

Выполнив поэтапно шаги из данной статьи, получится рабочая версия БД со схемой master-slave. Статья не претендует на уникальность и что нужно делать именно так, но с такими параметрами у меня всё заработало.