Настройка репликации 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:
/etc/percona-server.conf.d/mysqld.cnf

[client]
port = 3306
socket = /mnt/u01/mysql/data/mysqld.sock
default-character-set = utf8

[mysqld_safe]
nice = 0
socket = /mnt/u01/mysql/data/mysqld.sock

[mysqld]

# default settings
datadir=/mnt/u01/mysql/data/
socket=/mnt/u01/mysql/data/mysqld.sock
user = mysql
port = 3306
skip-external-locking
default-storage-engine = innodb
pid-file = /var/run/mysqld/mysqld.pid
transaction-isolation = READ-COMMITTED
max_allowed_packet = 16M
myisam-recover-options = BACKUP
explicit_defaults_for_timestamp = 1
expire_logs_days = 10
max_binlog_size = 100M
sql_mode = “”

# Cache parameters
query_cache_size = 32M
table_open_cache = 4096
thread_cache_size = 32
key_buffer_size = 16M
thread_stack = 128K
join_buffer_size = 2M
sort_buffer_size = 2M

# Parameters for temporary tables
tmpdir = /tmp
max_heap_table_size = 32M
tmp_table_size = 32M

# InnoDB parameters
innodb_file_per_table
innodb_buffer_pool_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT

# Database charset parameters
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = “SET NAMES utf8 COLLATE utf8_unicode_ci”
#skip-character-set-client-handshake
skip-name-resolve

# Logging
log_error=/var/log/mysqld.log
pid_file=/var/run/mysqld/mysqld.pid

# Replication
gtid_mode = ON
log_bin = mysql-bin
log-slave-updates
enforce-gtid-consistency
server_id = 1
replicate-do-db = db_name
sync_binlog = 0
innodb_strict_mode=0

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8

[isamchk]
key_buffer = 16M

В конфигурационном файле 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:
/etc/percona-server.conf.d/mysqld.cnf

[client]
port = 3306
socket = /mnt/u01/mysql/data/mysqld.sock
default-character-set = utf8

[mysqld_safe]
nice = 0
socket = /mnt/u01/mysql/data/mysqld.sock

[mysqld]

# default settings
datadir=/mnt/u01/mysql/data/
socket=/mnt/u01/mysql/data/mysqld.sock
user = mysql
port = 3306
skip-external-locking
default-storage-engine = innodb
pid-file = /var/run/mysqld/mysqld.pid
transaction-isolation = READ-COMMITTED
max_allowed_packet = 16M
myisam-recover-options = BACKUP
explicit_defaults_for_timestamp = 1
expire_logs_days = 10
max_binlog_size = 100M
sql_mode = “”

# Cache parameters
query_cache_size = 32M
table_open_cache = 4096
thread_cache_size = 32
key_buffer_size = 16M
thread_stack = 128K
join_buffer_size = 2M
sort_buffer_size = 2M

# Parameters for temporary tables
tmpdir = /tmp
max_heap_table_size = 32M
tmp_table_size = 32M

# InnoDB parameters
innodb_file_per_table
innodb_buffer_pool_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT

# Database charset parameters
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = “SET NAMES utf8 COLLATE utf8_unicode_ci”
#skip-character-set-client-handshake
skip-name-resolve

# Logging
log_error=/var/log/mysqld.log
pid_file=/var/run/mysqld/mysqld.pid

# Replication
server-id=2
gtid_mode=ON
enforce-gtid-consistency
replicate-do-db = db_name
innodb_strict_mode=0

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8

[isamchk]
key_buffer = 16M
EOF

Дальнейшие действия выполняются из статьи по настройке репликации в 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 – это самое главное.

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

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: