Настройка репликации MySQL Master-Slave: GTID, мониторинг, ошибки

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

Что даёт репликация 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%.

Типичные сценарии сбоев