Что происходит, если падает Master реплика?

Что происходит при падении Master-реплики?

Когда Master-реплика (также называемая primary или leader) в системах репликации данных (PostgreSQL, MySQL, MongoDB, Redis и др.) падает, запускается процесс отказа (failover), который критически важен для обеспечения доступности данных. Конкретный сценарий зависит от конфигурации и используемых инструментов, но общая последовательность событий такова:

1. Обнаружение сбоя (Failure Detection)

Health-check механизмы (встроенные в СУБД или внешние, например, Patroni, Orchestrator, Redis Sentinel, MongoDB Replica Set Heartbeats) периодически опрашивают master-узел. При отсутствии ответа в течение заданного таймаута master помечается как недоступный. Таймауты настраиваются для баланса между скоростью реакции и устойчивостью к ложным срабатываниям из-за сетевых задержек.

2. Инициирование процесса отказов (Failover Initiation)

После обнаружения сбоя система переходит к выбору нового мастера. Происходит следующее:

• Автоматический или ручной failover: В автоматическом режиме система сама выбирает и продвигает новую реплику. В ручном режиме администратор подтверждает действие.
• Критерии выбора нового мастера: Обычно выбирается наиболее актуальная реплика (с минимальным отставанием), часто с приоритетом, заданным в конфигурации.

3. Выбор и продвижение нового мастера (Promotion)

Одна из slave-реплик (standby, secondary) переводится в режим read-write и становится новым мастером.

-- Пример в PostgreSQL (ручное продвижение с pg_promote)
SELECT pg_promote();

Для этого реплика должна завершить применение всех оставшихся WAL (Write-Ahead Log) или бинарных логов, чтобы гарантировать консистентность данных.

4. Перенаправление трафика (Traffic Redirect)

Клиентские подключения к старому мастеру разрываются. Чтобы приложения могли продолжить работу:

• Обновляются записи DNS (если используется).
• Меняется конфигурация балансировщиков нагрузки (HAProxy, Nginx).
• Используются специальные прокси-агенты (например, PGBouncer с переключением).
• Приложения могут использовать встроенные механизмы переподключения и определения мастера через конфигурационные файлы или сервисы обнаружения (Consul, etcd).

5. Реконфигурация репликации (Replication Reconfiguration)

Остальные реплики перенастраиваются на чтение данных с нового мастера. Старый мастер, если он вернется в строй, обычно становится репликой нового мастера.

# Пример настройки реплики PostgreSQL на нового мастера
primary_conninfo = 'host=new-master-host port=5432 user=replicator password=xxx'

6. Риски и потенциальные проблемы

Процесс отказоустойчивости не всегда проходит гладко. Возможны следующие проблемы:

• Потеря данных (Data Loss): Если мастер падает до того, как успеет отправить все транзакции репликам, эти данные могут быть потеряны. Настройки вроде synchronous_commit в PostgreSQL или semisync в MySQL минимизируют, но не всегда исключают этот риск.
• Split-brain (раздвоение мозга): Крайне опасная ситуация, когда два узла одновременно считают себя мастерами. Это может привести к повреждению данных. Для предотвращения используются квиорум, арбитры реплик (MongoDB) и надежные механизмы консенсуса (Raft, используемый в Patroni).
• Увеличение задержки репликации: Новая топология может быть географически неоптимальна.
• Проблемы с клиентскими подключениями: Приложения должны корректно обрабатывать разрывы соединений и повторно подключаться.
• Необходимость мониторинга и алертинга: Администраторы должны быть уведомлены о сбое для возможного ручного вмешательства.

7. Роль администратора после failover

После автоматического переключения задачи администратора включают:

• Анализ причин падения исходного мастера (аппаратная неисправность, перегрузка, сетевая проблема).
• Восстановление старого мастера и его включение в кластер в качестве реплики.
• Проверка целостности данных и мониторинг задержки репликации.
• Обновление документации и конфигураций при необходимости.

Заключение

Падение мастера — критическое, но управляемое событие. Успешное автоматическое восстановление зависит от корректной настройки механизмов репликации, надежной системы обнаружения сбоев и отлаженной процедуры failover. Современные инструменты оркестрации (Patroni, Orchestrator) значительно автоматизируют этот процесс, минимизируя время простоя (downtime). Тем не менее, наличие подготовленного плана аварийного восстановления (Disaster Recovery Plan) и регулярное тестирование процедуры переключения в staging-среде остаются обязательной практикой для поддержания высокой доступности сервиса.