Чим GTID відрізняється від класичної реплікації за координатами

У класичній схемі реплікації репліка запам'ятовує файл і позицію у бінлозі майстра, звідки продовжувати читання — це пара MASTER_LOG_FILE і MASTER_LOG_POS. Після зміни майстра ці координати доводиться шукати вручну, звіряючи логи, і помилка на пару байтів псує всю реплікацію.

GTID (Global Transaction Identifier) надає кожній транзакції унікальний ідентифікатор вигляду server_uuid:номер. Репліка зберігає набір уже застосованих GTID і під час перемикання сама обчислює, з якої транзакції продовжувати — без ручного пошуку файлу і позиції.

Як увімкнути GTID на майстрі та репліках

Режим вмикається однаковими параметрами на всіх вузлах:

[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = /var/lib/mysql/binlog
server_id = 10

Параметр enforce_gtid_consistency забороняє конструкції, які не можна однозначно прив'язати до однієї транзакції — наприклад, змішування тимчасових і звичайних таблиць в одному запиті. Вмикати його потрібно до переведення реплікації на GTID, інакше сервер відмовиться запускатися з наявними проблемними запитами в логах.

Налаштування репліки через MASTER_AUTO_POSITION

Замість файлу і позиції репліка вказує лише адресу майстра:

CHANGE MASTER TO
  MASTER_HOST='10.0.0.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='strong-pass',
  MASTER_AUTO_POSITION=1;

START SLAVE;

Прапорець MASTER_AUTO_POSITION=1 каже серверу звірити набір GTID на репліці з набором на майстрі і запросити саме відсутні транзакції. Базові кроки налаштування користувача для реплікації та самого каналу описані у статті про Master-Slave реплікацію.

Перемикання на нового майстра без втрати позиції

Головна перевага GTID проявляється під час аварії майстра. Порядок дій:

Крок	Дія
1	Зупинити запис на старому майстрі або підтвердити його недоступність
2	Обрати репліку з найповнішим набором GTID через SHOW SLAVE STATUS
3	Виконати CHANGE MASTER TO з адресою нової репліки-майстра
4	Запустити START SLAVE на інших репліках
5	Перевірити Seconds_Behind_Master і Executed_Gtid_Set на кожному вузлі

Оскільки GTID глобально унікальний для всього кластера, репліки не запросять повторно вже застосовані транзакції і не втратять події між старим і новим майстром, якщо вони перемикалися на актуальну копію.

Діагностика: розрив у наборі GTID

Найчастіша проблема — errant transaction, транзакція, виконана прямо на репліці в обхід майстра. Вона псує набір GTID і зупиняє реплікацію з помилкою дубліката. Знайти її допомагає порівняння множин:

SELECT GTID_SUBTRACT(
  @@GLOBAL.gtid_executed,
  'source-uuid:1-500'
) AS extra_transactions;

Якщо результат не порожній, на репліці є транзакції, яких немає на майстрі, — їх потрібно або пропустити через GTID_NEXT, або повністю переналаштувати репліку зі свіжого бекапу.

Часті помилки під час переходу на GTID

Перед увімкненням GTID на проді варто перевірити:

На всіх вузлах binlog у форматі ROW, а не STATEMENT.
server_id унікальний для кожного вузла кластера, включно з резервними репліками.
Немає прямих записів на репліки в обхід майстра, які створюють errant transactions.
Перевірена процедура перемикання на тестовому стенді, а не лише в теорії.

Чек-лист перед введенням GTID у продакшен

Фінальна перевірка перед перемиканням робочої реплікації:

gtid_mode = ON і enforce_gtid_consistency = ON на майстрі та всіх репліках.
CHANGE MASTER TO використовує MASTER_AUTO_POSITION=1 всюди.
Executed_Gtid_Set звірений між вузлами і не показує розбіжностей.
Є свіжий повний бекап на випадок, якщо перемикання піде не за планом.
Моніторинг Seconds_Behind_Master налаштований і надсилає алерт при відставанні.

GTID-реплікація MySQL: налаштування і зміна майстра