Данная статья содержит теорию по репликации с GTID в MySQL, практическая реализация на примере БД для Битрикс24
Теория
GTID появился с MySQL 5.6 и представляет собой 128-битный идентификационный номер (SERVER_UUID), который увеличивается с каждой новой транзакцией.
Выглядит GTID примерно так:
8182213e-7c1e-11e2-a6e2-080027635ef5
Ранее репликация была завязана но бинарный лог и позицию в нём, теперь благодаря GTID не нужно разбираться с вычислениями, проверками бинарных логов и т.д. Подробную теорию можно дополнительно изучить на оф. сайте, но для начала необходимо просто понимать, что использование GTID – это хорошая практика.
В MySQL есть две глобальные переменные:
gtid_executed – содержит в себе набор всех транзакций, которые есть в бинарном логе
gtid_purged – содержит набор транзакций, которые были удалены из бинарного лога.
На мастере это выглядит так:
master > show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
master > show global variables like 'gtid_purged';
+---------------+------------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------------+
| gtid_purged | 9a511b7b-7059-11e2-9a24-08002762b8af:1-2 |
+---------------+------------------------------------------+
Для настройки репликации в конфиге мастера достаточно прописать:
gtid_mode=ON
log_bin=mysql-bin
log-slave-updates
enforce-gtid-consistency
server_id=1
replicate-do-db = mybase
Описание используемых параметров в конфигурационном файле мастера:
gtid_mode=ON # собственно, включает GTID
log_bin=mysql-bin # Ведение бинарного лога для мастера (с него читает слейв). Когда на сервере используются GTID, и если бинарный лог не включен, при перезапуске сервера после аварийного выключения, некоторые GTID могут быть потеряны, что приведет к сбою репликации. При обычном завершении работы набор идентификаторов GTID из бинарного лога сохраняется в таблице mysql.gtid_executed
enforce-gtid-consistency # обязательный параметр для GTID, который не даёт всё поломать
server_id=1 # идентификатор мастер сервера, цифровое значение может быть отличным от единицы в данном примере
replicate-do-db = mybase # база для репликации
Описание не используемых, но возможных параметров в конфигурационном файле мастера помимо вышеописанных:
log-slave-updates = 0 – необходим при использовании схемы А -> Б -> C, где А – гл. сервер для Б, а Б – гл. сервер для С, т.к. “гирляндная” или последовательная схема.
sync_binlog = 0 – используется для синхронизации всех транзакций с двоичным файлом. По факту повышает надёжность транзакций для слейва при отказе ОС в случае сбоя. А также сильно влияет на производительность I\O хранилища, поэтому можно либо его отключить и положиться на надёжность отказоустойчивости, или же включить при наличии скоростного хранилища. В общем, использовать или нет – зависит от требований. Я не использую.
На слейве использование log_bin=mysql-bin вовсе не обязательно. Т.к. идентификаторы GTID бинлога хранятся в таблице mysql.gtid_executed мастера, слейв будет читать их оттуда.
Исходя из вышеописанного, на слейве параметры слелующие:
#log-bin=mysql-bin - не обязательно при использовании GTID
server-id=2
gtid_mode=ON
enforce-gtid-consistency
replicate-do-db = mybase
Дамп будет содержать следующую запись:
grep PURGED dump1.sql
SET @@GLOBAL.GTID_PURGED='9a511b7b-7059-11e2-9a24-08002762b8af:1-13';
При выполнении mysqldump, есть интересный параметр –set-gtid-purged=OFF, который позволяет управлять информацией глобальных идентификаторов транзакций (GTID), записанной в файл дампа, указывая, добавлять ли оператор SET @@ global.gtid_purged в вывод дампа.
–single-transaction в данном случае прописан, т.к. используется движок InnoDB.
Исходя из вышеописанного, после распаковки дампа на слейве, GTID_PURGED будет иметь значение GTID_EXECUTED мастера
Если не включить параметр –set-gtid-purged=OFF, и распаковать дамп, то можно на на слейве увидеть появившиеся значения:
slave1 > show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
slave1 > show global variables like 'gtid_purged';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_purged | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
Оф. документация MySQL:
https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-concepts.html#replication-gtids-gtid-executed-table
https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-howto.html