Настройка репликации MySQL с GTID в Bitrix

Введение

Когда-то давно мною была написана статья по настройке репликации в MySQL. Но данный способ имеет один нюанс: данный метод блокирует публичную часть сайта и начинает дропать все таблицы и переносить их заново. Так происходит, потому что репликация в MySQL заранее не настроена, и первичная настройка выполняется через интерфейс битрикса. В общем, есть некоторые неудобства данного способа.

Также я писал про другой метод репликации Master-Slave в MySQL с использованием GTID. И вот теперь можно применить его при настройке репликации MySQL в битрикс, чтобы избежать проблем из первоначальной статьи и всё сделать правильно.

В данной статье будет рассказано о настройке репликации MySQL для Битрикс24 с использованием GTID. Описанные шаги также применимы и к настройке репликации с GTID уже на работающем сервере MySQL.

Также перед началом хочу заметить, что лучше исключить из репликации таблицы b_sec_session, если сессии хранятся в БД, т.к. сами битриксы говорят, что это вызывает глюки при большой нагрузке. В данном мануале я делать этого не буду, т.к. это выходит за рамки статьи, но реализовать не сложно.

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

• Используемый форк MySQL – Percona 5.7.30
• Конфиг по пути /etc/percona-server.conf.d/mysqld.cnf
• Директория для MySQL – /mnt/u01/mysql/data

Подготовка Master-сервера

• Подразумевается, что основной сервер уже введен в работу. Минимально рабочий конфигурационный файл для MySQL Master:

В конфигурационном файле MySQL необходимо изменить следующие параметры в зависимости от доступной оперативной памяти и физического размещения MySQL на сервере:

• datadir – путь, где физически располагаются файлы MySQL. В данной инструкции предполагается, что это директория /mnt/u01/mysql/data
• socket – путь до сокета для консольного клиента, в той же директории /mnt/u01/mysql/data
• innodb_buffer_pool_size – требует тонкой настройки, для начала можно выставить в 50% от свободной оперативной памяти (значение в 4096М или 4G – мегабайты или гигабайты соответственно).
• server-id – в зависимости от роли Master или Slave
• innodb_strict_mode=0 – данный параметр нужно указать явно в конфиге

Прочие параметры можно оставить по умолчанию, они подлежат корректировке в случае необходимости.

Вышеописанный конфиг был взят из виртуальной машины bitrix для конфигурации: HDD, 1vCPU, 2 RAM. Он не является универсальным и должен настраиваться индивидуально.

Подготовка Slave-сервера

Настройки слейва почти не отличаются от настроек мастера, за исключение конфигурационного файла MySQL.

• Конфигурационный файл для MySQL Slave:

Дальнейшие действия выполняются из статьи по настройке репликации в MySQL, после чего можно переходить к настройке репликации для Битрикс24.

Для продолжения должна быть настроенная репликация на уровне MySQL, чтобы битрикс подхватил настроенный слейв на уровне приложения.

Создание учётных записей

Некоторые сложности в настройке репликации Master-Slave для Битрикс могут вызывать учетные записи, которые представлены в количестве трёх штук. В официальной документации битрикса вроде бы описан процесс, но может показаться недостаточно подробным и понятным, поэтому ниже будут инструкции с пояснениями по созданию необходимых учетных записей для корректной настройки репликации с моими дополнениями.

Всего необходимо три учётки:

1. Основная УЗ из dbconn.php и .settings.php – для подключения и работы приложения с БД;
2. УЗ для управления слейв-серверами из веб-интерфейса битрикс;
3. УЗ для подключения сервера реплики к мастеру и работы непосредственно самой репликации.

Для каждой из вышеописанных УЗ необходимы отдельные права:

• Для основной УЗ необходимы все права на БД, с которой работает приложение:

master> GRANT ALL PRIVILEGES ON DB_NAME.* TO 'user'@'APP_SRV_IP' identified by "Strong_PASS!";

И REPLICATION CLIENT для получения статистики с мастера, но на все базы:

master> GRANT REPLICATION CLIENT ON *.* TO 'user'@'APP_SRV_IP' identified by "Strong_PASS!";

Без права REPLICATION CLIENT на все БД для основной УЗ приложения настроить реплику из админки битрикса не получится! В документации битрикс про это не написано.

• Для УЗ по управлению слейвами из веб-интерфейса нужен следующий перечень прав:

slave> GRANT SELECT,LOCK TABLES,CREATE TEMPORARY TABLES,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON DB_NAME.* TO 'bitrix-ui'@'APP_SRV_IP' identified by "$tr0ng_pw!";

А также REPLICATION CLIENT и SUPER для управления слейвами, но уже на уровне всех БД:

slave> GRANT REPLICATION CLIENT,SUPER ON *.* TO 'bitrix-ui'@'APP_SRV_IP' identified by "$tr0ng_pw!";

• Для выполнения непосредственно репликации следующие права:

master> GRANT REPLICATION SLAVE on *.* TO 'bitrix_replica'@'APP_SRV_IP' identified by 'replic@_pw!!!';

С одной стороны, всё разделено по учеткам, используются разные пароли и права, что более безопасно. Но с другой выглядит это немного запутанным и усложняет администрирование и отладку.

• Поэтому для тех, кто не хочет заморачиваться с разным количеством учеток, можно выдать все необходимые права только для одной, которая необходима для работы приложения, и указана в dbconn\settings:

master> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'APP_SRV_IP' identified by 'pass_from_dbconn.php';

master> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'SLAVE_SRV_IP' identified by 'pass_from_dbconn.php';

slave> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'APP_SRV_IP' identified by 'pass_from_dbconn.php';

slave> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'MASTER_SRV_IP' identified by 'pass_from_dbconn.php';

• APP_SRV_IP – IP-адрес сервера приложений, где запущен веб-сервер;
• MASTER_SRV_IP – IP-адрес основного ведущего сервера MySQL;
• SLAVE_SRV_IP – IP-адрес подчиненного сервера MySQL.

• Очистить привилегии:

flush privileges;

На боевом мастер-сервере с БД стоит внимательно выдавать права. При допущении ошибок, работа приложения может быть нарушена!

Настройка репликации на уровне Битрикс24

На данном этапе осталось лишь подхватить созданный слейв в админке битрикса.

• В административной панели зайди в модуль “Веб-кластер“-> Группа #1-> Репликация
• Нажать “Добавить Slave базу данных“, пройти проверку при создании слейва
• Несмотря на красные пункты, можно продолжать далее – это всего лишь рекомендации и дальнейшей настройке они не помешают:

Особое внимание нужно обратить на файлы bitrix/php_interface/after_connect.php и bitrix/php_interface/after_connect_d7.php. Для настройки репликации их необходимо удалить, чтобы мастер битрикса прошёл проверку. Но в данном файле указываются некоторые настройки для БД, в частности, директива innodb_strict_mode=0, которую нужно указать в конфигурационном файле mysqld.cnf, о чём было сказано в самом начале статьи в абзаце с примерами конфигов.

• Далее в появившемся окне необходимо указать адрес слейва, а также УЗ для управления слейвами из интерфейса (bitrux-ui) или же указать УЗ из dbconn, если отдельные УЗ не создавались:

• После остается указать имя соединения для репликации и, если всё было сделано правильно, слейв подхватится и будет активным. Запросы на чтение будут приходить уже на новый слейв.

Заключение

В статье был рассмотрен способ настройки репликации Master-Slave в MySQL для Битрикс24 с учётом его особенностей. Особых сложностей возникнуть не должно, если репликация заранее уже настроена в самом MySQL – это самое главное.

Способ выдачи прав для репликации – всё для одной учетки или для трёх отдельных – дело сугубо индивидуальное. Рекомендуется отталкиваться исходя из потребностей, но не забывать про безопасность.