Multi-source репликация MySQL5.7

Появилась нужда в настройке multi-source репликации MySQL, т.е. с нескольких master-серверов будем лить в один slave-сервер. Настройка репликации будет производиться с использованием GTID.

GTID - это уникальный идентификатор, который создается и ассоциируется с каждой завершенной (commit) транзакцией на master сервере. Эта транзакция уникальна для всех серверов - участников репликации. Таким образом, когда транзакция клиента выполнена (commit) и записана в бинарный лог на сервере-источнике, ей присваивается новый GTID. Каждый идентификатор GTID монотонно увеличивается, без промежутков в нумерации.

GTID представляет из себя пару координат, разделенных двоеточием. Например: GTID = source_id:transaction_id или GTID = 3E00FA47-22CA-01E1-9E33-C80UU9429452:23, где

source_id      - значение server_uuid мастер-сервера
transaction_id - порядковый номер транзакции

В новых версиях MySQL/MariaDB формат GTID изменился и упростился

В MySQL при использовании GTID есть две глобальные переменные, о которых необходимо знать

gtid_executed – содержит набор всех транзакций из бинарного лога
gtid_purged   – содержит набор транзакций, которые были зафиксированы на сервере, но не содержащиеся в бинарном логе, gtid_purged является подмножеством gtid_executed

Для репликации с использованием GTID в MySQL в конфиге мастера достаточно прописать следующие значение

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

gtid_mode = ON - собственно, включает GTID
enforce-gtid-consistency = ON - обязательный параметр для GTID, который не даёт всё поломать(без этого параметра не стартует MySQL с gtid)
log_bin = mysql-bin - ведение бинарного лога для мастера (с него читает слейв). Когда на сервере используются GTID, и если бинарный лог не включен, при перезапуске сервера после аварийного выключения, некоторые GTID могут быть потеряны, что приведет к сбою репликации. При обычном завершении работы набор идентификаторов GTID из бинарного лога сохраняется в таблице mysql.gtid_executed
server_id = 1 идентификатор мастер сервера, цифровое значение может быть отличным от единицы в данном примере

На слейве использование log_bin = mysql-bin не обязательно, т.к. идентификаторы GTID бинлога хранятся в таблице mysql.gtid_executed мастера - слейв будет читать их оттуда. Для слейва минимальный конфиг репликации примерно такой

server-id                 = 2
gtid_mode                 = ON
enforce-gtid-consistency  = ON
master_info_repository    = TABLE
relay_log_info_repository = TABLE

Ну что ж, как говорится, от теории к практике.

Создаём пользователя для репликации

mysql> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'%' IDENTIFIED BY 'repl_pass';

Конфиг мастера

gtid_mode                       = ON
enforce-gtid-consistency        = ON
server_id                       = 1
log_bin                         = /var/lib/mysql/binlog/binlog
#log_bin_index                   = /var/lib/mysql/binlog/binindex
sync_binlog                     = 0
log_slave_updates               = OFF

Проверяем состояние мастера:

mysql> show master status;

Конфиг слейва

https://habr.com/ru/post/276581/
https://www.k-max.name/linux/replikaciya-mysql-master-slave/
https://it-lux.ru/%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F-mysql-%D1%81-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC-gtid/
https://www.percona.com/blog/2013/10/02/mysql-5-7-multi-source-replication/
https://dev.mysql.com/doc/refman/5.7/en/replication-multi-source.html