Налаштування реплікації MySQL Master-Slave: GTID, моніторинг, помилки

Зазначимо: коли primary-сервер MySQL падає, бізнес втрачає не лише час, а й транзакції — відновлення з бекапів може зайняти години. На одному проєкті з навантаженням 5000 запитів на секунду простій тривав 4 години, що призвело до збитків. Реплікація MySQL Master-Slave вирішує цю проблему: replica копіює бінарний лог з master і застосовує події з лагом у мілісекунди. Професійне налаштування реплікації Master-Slave — це не лише резервний сервер, а й можливість розподіляти запити читання, знижуючи навантаження на primary. У цій статті — практична конфігурація, типові помилки, моніторинг лагу та що ми включаємо в роботу. Стабільна реплікація з GTID скорочує час failover до хвилин, а при нормальному навантаженні лаг не перевищує 1–2 секунд. GTID-реплікація працює в 3–5 разів швидше за позиційну при відмові майстра.

Що дає реплікація Master-Slave?

• Відмовостійкість: при відмові master перемикаємось на replica за хвилини.
• Масштабування читання: відправляємо SELECT на кілька реплік, залишаючи master для запису.
• Бекапи без зупинок: робимо дамп з replica, не впливаючи на production.

Більшість проєктів приходять до реплікації після першого збою. Ми рекомендуємо налаштовувати її на старті: це дешевше та швидше, ніж екстрено відновлювати дані.

Покрокове налаштування реплікації MySQL

Налаштування Master

На master вмикаємо бінарний лог і задаємо server_id. Приклад конфігурації:

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
server_id = 1
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_row_image = MINIMAL
sync_binlog = 1
expire_logs_days = 7

Створюємо користувача з правами REPLICATION SLAVE:

CREATE USER 'repl'@'10.0.0.2' IDENTIFIED WITH caching_sha2_password BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.2';
FLUSH PRIVILEGES;

Зняття початкового дампу

Для ініціалізації репліки потрібен дамп з позицією бінлогу. Два способи:

Позиція бінлогу буде на початку дамп-файлу або в xtrabackup_binlog_info. На нещодавньому проєкті з 500 ГБ даних XtraBackup скоротив час дампу в 3 рази порівняно з mysqldump.

Налаштування Replica

На replica — свій server_id і режим read_only:

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
server_id = 2
relay_log = /var/log/mysql/mysql-relay
read_only = ON
log_bin = /var/log/mysql/mysql-bin
log_slave_updates = ON

Відновлюємо дамп і запускаємо реплікацію:

mysql -u root -p < /backup/full_dump.sql
mysql -e "CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.1', SOURCE_USER='repl', SOURCE_PASSWORD='repl_password', SOURCE_LOG_FILE='mysql-bin.000042', SOURCE_LOG_POS=12345, SOURCE_SSL=1; START REPLICA; SHOW REPLICA STATUS\G"

Перевіряємо: Replica_IO_Running: Yes, Replica_SQL_Running: Yes, Seconds_Behind_Source — лаг у секундах.

GTID чи позиційна реплікація?

GTID (Global Transaction ID) — глобальні ідентифікатори транзакцій, доступні з MySQL 5.6 і вище. Їх головна перевага — не потрібно вручну вказувати файл і позицію бінлогу. При failover replica сама визначає, які транзакції застосувати. MySQL Documentation: GTID transactions are globally unique. Завдяки GTID час failover скорочується з 10–15 хвилин до 2–3 хвилин, що знижує втрати при високонавантажених проєктах. Налаштування GTID:

gtid_mode = ON enforce_gtid_consistency = ON 

Команда CHANGE використовує SOURCE_AUTO_POSITION=1 замість вказівки файлу та позиції. GTID також спрощує пропуск помилкових транзакцій — замість SQL_SLAVE_SKIP_COUNTER використовуємо SET GTID_NEXT='...'; BEGIN; COMMIT;.

Якщо ваша версія MySQL 5.6+ і ви плануєте часто перемикати майстра, вибирайте GTID. Для старих версій (5.5 і нижче) доступна лише позиційна реплікація. На етапі проєктування ми допомагаємо визначити оптимальний варіант під ваше навантаження та SLA.

Моніторинг та управління лагом реплікації

Лаг — різниця в часі між комітом транзакції на master та її застосуванням на replica. Він вимірюється в секундах через Seconds_Behind_Source. При нормальному навантаженні лаг не перевищує 1–2 секунд. Якщо лаг зростає, перевірте:

• продуктивність диска на replica;
• розмір транзакцій (великі DDL можуть збільшити лаг);
• мережеві затримки.

Моніторинг лагу — через mysqld_exporter метрику mysql_slave_status_seconds_behind_master. Алерт при лазі > 30 секунд та > 60 секунд.

При високому лазі (більше 30 секунд) спочатку перевірте навантаження на replica: якщо CPU або I/O впираються, збільште ресурси або додайте паралельних робочих (slave_parallel_workers). Якщо проблема в мережі (затримка >5 мс), розгляньте перехід на виділений VLAN або географічне розміщення реплік.

Для прискорення реплікації використовуйте binlog_format = ROW та binlog_row_image = MINIMAL — це зменшує обсяг переданих даних. Також збільште slave_parallel_workers до 4-8, якщо версія MySQL 8.0+. На потужному сервері це дає приріст продуктивності до 50%.

Типові сценарії збоїв