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-howto.html
