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

Последнее обновление 04.10.2019

Что касается репликации в битриксе, то по этому вопросу уже была написана обширная статья. Но спустя время был выявлен один нюанс: данный метод блокирует публичную часть сайта и начинает дропать все таблицы и переносить их заново. А если база по 20, 200, 1000 гб? Ждать приходится очень долго. Если на небольшом проекте такой вариант еще прокатит, то при использовании в продакшене, где ограничено время на выполнение работ, придётся столкнуться с гневным заказчиком.

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

Более подробное описание метода и используемых параметров можно найти в оф. документации и применение того или иного зависит от конкретных целей.

Конфигурационный файл будущего мастера с настройками репликации:

gtid_mode=ON
log_bin=mysql-bin
log-slave-updates
enforce-gtid-consistency
server_id=1
replicate-do-db = mybase

Конфигурационный файл будущего слейва с настройками репликации:

server-id=2
gtid_mode=ON
enforce-gtid-consistency
replicate-do-db = mybase

Далее поэтапно:

  • Снятие дампа с мастера с сохранением записей о GTID
mysqldump --single-transaction mybase > mybase.sql
  • Передача дампа любым удобным способом на слейв и распаковка:

Непосредственно перед началом раздампа убедиться, что слейв “чистый” и не остались следы прошлых репликаций, если таковые были:

reset master;
cat mybase | mysql mybase
  • Далее следует настройка прав на мастере. К серверу БД, которым будет являться мастер, должны подключаться сервер (или сервера, если их несколько) приложений и сервер с БД слейва с учетной записью, которая прописана в dbconn.php или .settings.php:
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user_from_dbconn'@'Bitrix_server_IP' identified by 'oAwGU50XKi.1G'; # APP1
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user_from_dbconn'@'Slave_server_IP' identified by 'oAwGU50XKi.1G'; # Slave

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

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user_from_dbconn'@'Bitrix_server_IP' identified by 'oAwGU50XKi.1G'; # APP1
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user_from_dbconn'@'Master_server_IP' identified by 'oAwGU50XKi.1G'; # Master
  • После настройки всех прав необходимо указать адрес мастера и логин\пароль на Slave, которые уже были использованы:
CHANGE MASTER TO MASTER_HOST="Master_server_IP", MASTER_PORT=3306, MASTER_USER="user_from_dbconn", MASTER_PASSWORD="oAwGU50XKi.1G", MASTER_AUTO_POSITION=1;
  • И запуск репликации на slave:
start slave;

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

  • Через модуль “Веб-кластер” пройти проверку при создании слейва
  • Несмотря на красные пункты, можно продолжать далее – это всего лишь рекомендации и дальнейшей настройке они не помешают.
  • После остается указать имя соединения для репликации и, если всё было сделано правильно, слейв подхватится без всяких дополнительных проверок и закрытия публичной части.

Ваш комментарий будет первым

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *