Репликация MySQL с использованием GTID

Данная статья содержит теорию по репликации с 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 |
+---------------+-------------------------------------------+