Что произойдет со Slaves, если Master выйдет из строя?

Репликация MySQL и состояние Slaves при потере Master

В контексте репликации базы данных (например, MySQL) Master (основной сервер) отвечает за обработку всех операций записи, а Slaves (серверы-реплики) непрерывно получают изменения с Master и применяют их на себе, обеспечивая чтение данных и отказоустойчивость. Если Master выходит из строя, состояние и поведение Slaves зависят от конкретной конфигурации репликации и предпринятых административных действий.

Исходное состояние Slaves после сбоя Master

Когда Master становится недоступным, все Slaves переходят в состояние ожидания:

1. Прекращение получения бинарного лога (Binary Log): Процесс репликации на каждом Slave (I/O Thread) останавливает чтение новых событий из бинарного лога Master, поскольку соединение разрывается.
2. Завершение обработки накопленных событий: SQL Thread на каждом Slave продолжает применять события, которые уже были загружены в его relay log, до его окончания. После этого процесс репликации полностью остановится.
3. Статус репликации: В MySQL команда SHOW SLAVE STATUS покажет для Slave_IO_Running значение No (поток чтения остановлен), а для Slave_SQL_Running — Yes или No, depending on whether the relay log has been fully processed. Поле Last_IO_Error будет содержать ошибку соединения, например, error reconnecting to master.

-- Пример вывода SHOW SLAVE STATUS после сбоя Master
SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Slave_IO_Running: No
                  Slave_SQL_Running: Yes
                Last_IO_Error: 2023-10-05 10:30:00 Error connecting to master: Can't connect to MySQL server on 'master_host' (111)

Дальнейшие действия и возможные стратегии восстановления

После остановки репликации необходимо предпринять действия для восстановления работоспособности системы. Ключевые решения:

1. Восстановление оригинального Master (если возможно)

Если Master можно быстро восстановить (reboot, restore from backup), Slaves можно просто перезапустить, и репликация продолжится после восстановления соединения. Однако это создает период полной недоступности для операций записи.

2. Переключение на один из Slaves как новый Master (Promotion)

Это стандартная процедура повышения отказоустойчивости. Один из Slaves назначается новым Master, а остальные Slaves переключаются на репликацию с него.

Процесс promotion Slave в Master:

• На выбранном Slave: Остановить репликацию (STOP SLAVE), убедиться, что все данные применены, и включить возможность записи (read_only = 0).
• На остальных Slaves: Настроить репликацию с нового Master, обновив параметры MASTER_HOST, MASTER_LOG_FILE, MASTER_LOG_POS на основе данных с нового Master.

-- На Slave, который станет новым Master
STOP SLAVE;
RESET SLAVE ALL; -- Очистить информацию о старом Master
SET GLOBAL read_only = 0;

-- На другом Slave, чтобы начать репликацию с нового Master
STOP SLAVE;
CHANGE MASTER TO
    MASTER_HOST = 'new_master_ip',
    MASTER_USER = 'repl_user',
    MASTER_PASSWORD = 'password',
    MASTER_LOG_FILE = 'mysql-bin.000002',
    MASTER_LOG_POS = 154;
START SLAVE;

3. Использование механизмов автоматического переключения (Failover)

В современных решениях (MySQL Group Replication, MariaDB MaxScale, внешние кластерные менеджеры like Orchestrator или ProxySQL) процесс failover может быть автоматизирован. Эти системы отслеживают состояние Master и автоматически выполняют promotion наиболее подходящего Slave, минимизируя время недоступности.

Ключевые факторы, влияющие на процесс

• Расхождение данных (Data Drift): Если какой-то Slave получил и применил больше или меньше событий, чем другие, перед promotion необходимо обеспечить консистентность данных (например, проверить позицию в бинарном логе Exec_Master_Log_Pos).
• Полусинхронная репликация (Semisynchronous Replication): Если она использовалась, хотя один Slave гарантированно получил каждую транзакцию перед commit на Master, это может помочь выбрать наиболее актуальную реплику для promotion.
• Дополнительные реплики и топология: В сложных топологиях (цепочки реплик, параллельные реплики) процесс переключения требует более тщательного планирования, чтобы не нарушить цепочку данных.

Заключение

Таким образом, при выходе Master из строя Slaves не разрушаются или не удаляются, они переходят в состояние ожидания и сохраняют все примененные данные. Основной риск — это остановка операций записи в системе и потенциальное расхождение данных между репликами. Корректное восстановление требует либо ремонта оригинального Master, либо ручного или автоматического переключения (failover) на один из Slaves, который становится новым Master. Наличие надежной процедуры failover и регулярное тестирование этой процедуры являются критически важными компонентами любой production системы с репликацией базы данных.