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

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

Теперь на мастере надо сделать дамп, который распаковать после на слейв:

mysqldump --single-transaction --set-gtid-purged=OFF sitemanager > dump1.sql

Дамп будет содержать следующую запись:

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 мастера (в данном случае empty, т.к.–set-gtid-purged=OFF)

slave1 > show global variables like 'gtid_executed';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_executed |       |
+---------------+-------+
 
slave1 > show global variables like 'gtid_purged';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged   |       |
+---------------+-------+

Осталось залить дамп в базу:

cat dump1.sql | mysql sitemanager

Если не включить параметр –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 и выполнение на слейве команды:

CHANGE MASTER TO MASTER_HOST="192.168.10.176", MASTER_PORT=3306, MASTER_USER="bitrix0", MASTER_PASSWORD="8bny!@F&^2", MASTER_AUTO_POSITION=1;

Cам запуск слейва:

start slave;

Проверить можно через

show slave status \G

У пользователя для репликации, в данном случае bitrix0, должны быть необходимые права:

GRANT REPLICATION SLAVE ON *.* TO 'bitrix0'@'slave_host_ip' IDENTIFIED BY 'password';

В случае возникновения проблем (например, слейв был в дауне несколько дней и после запуска ругается на ошибки, как вариант ERROR 1238 (HY000): Variable ‘gtid_executed’ is a read only variable), правильный и хороший путь следующий: на слейве сбросить мастера, заново запустить раздамп и стартовать слейв.

reset master;
cat dump1.sql | mysql sitemanager
start slave;
Оф. документация 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

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

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

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