Как использовать failover в MySQL и обеспечить отказоустойчивость базы данных

Отказоустойчивость MySQL — критически важная часть любой инфраструктуры, где база данных является ключевым компонентом. Даже кратковременное отключение сервера БД может привести к остановке приложения, потере транзакций и финансовым убыткам.
Failover (автоматическое переключение на резервный сервер) позволяет минимизировать простой и обеспечить непрерывность работы сервисов.

В этой статье разберём основные подходы к отказоустойчивости MySQL, как организовать репликацию, что отвечает за автоматический failover и какие инструменты используют на практике.

Зачем нужен failover в MySQL

Failover решает сразу несколько проблем:

Автоматическое переключение на резервный сервер при падении мастера.
Минимизация простоя — приложение продолжает работать без ручного вмешательства.
Защита данных — в связке с репликацией обеспечивается почти полная непрерывность.
Повышение надёжности инфраструктуры — даже при проблемах с железом.

Group Replication
MySQL Router для переключения трафика
MySQL Shell для настройки

Пример структуры:

node1 — primary
node2 — secondary
node3 — secondary
mysql-router — направляет запросы на живой мастер

Failover происходит автоматически: если падает мастер, кластер выбирает нового лидера.

Пример инициализации кластера

var dba = require('dba');
var cluster = dba.createCluster("prodCluster");
cluster.addInstance("root@node2");
cluster.addInstance("root@node3");

Преимущества

полный автоматический failover
встроенный официальный инструмент
высокая согласованность данных

Недостатки

не работает с MyISAM
нужны стабильные сетевые соединения
сложнее миграция с обычной репликации

2. MHA (Master High Availability Manager)

Популярный инструмент для автоматического переключения мастера.

Как работает:

следит за мастером через мониторинговый узел
при падении — выбирает лучший слейв
продвигает его до мастера
обновляет конфигурации слейвов
возможен минимальный data loss

Плюсы MHA

быстрый failover (10–30 секунд)
зрелое и проверенное решение
довольно простая конфигурация

Минусы

требует внешнего менеджера
не полностью автоматический (может понадобиться скрипт восстановления)

3. Orchestrator (от GitHub, любимая тулза DevOps-ов)

Orchestrator — web-based система для управления репликацией и автоматического failover.

Возможности:

визуализация топологии репликации
автоматический failover
предотвращение «нестабильных» лидерств
перетаскивание реплик drag & drop через UI

Использует heartbeat-проверки, компенсирует лаги репликации, избегает split-brain.

Что происходит при failover (механика процесса)

Алгоритм примерно такой:

Обнаружение падения мастера (проверка ping/log/replication status)
Оценка состояния реплик:
- у какой минимальный lag
- у кого актуальный binary log
Выбор нового мастера
Обновление конфигурации остальных слейвов:

CHANGE MASTER TO MASTER_HOST='<new_master>';
START SLAVE;

Обновление маршрутизаторов (ProxySQL, HAProxy, MySQL Router)
Возврат старого мастера в кластер после восстановления (optional)

Как проксировать трафик при failover

Вариант 1: ProxySQL

Настраивается два пула:

writer_hostgroup = 10
reader_hostgroup = 20

При failover ProxySQL сам переключает write-нагрузку.

Вариант 2: HAProxy

Два бэкенда:

мастер
реплики

Используются mysql-checks для определения живого мастера.

Вариант 3: MySQL Router

Идеальный напарник для InnoDB Cluster.
Автоматически переподключает клиентов.

Практические рекомендации по настройке отказоустойчивости

Не используйте одинокий мастер: минимум 1 мастер + 2 реплики.
Размещайте ноды в разных дата-центрах, но не переусердствуйте — задержка важна.
Включайте semi-sync при критичных данных.
Проверяйте consistency при failover.
Логируйте все переключения — важно для аудита.
Тестируйте отказ вручную (simulated failover).

Что важно учитывать

Потеря последних транзакций возможна в асинхронной репликации.
Split-brain — опаснейший сценарий, его нужно предотвращать.
Не все приложения могут пережить failover без reconnect.
Пропуск GTID может создавать проблемы — лучше использовать GTID репликацию.

Итоги

Failover в MySQL — это не одна технология, а набор подходов:

InnoDB Cluster — официальный и наиболее автоматизированный вариант.
MHA — классика для простых продакшенов.
Orchestrator — мощное и гибкое решение с удобным управлением.

Выбор зависит от инфраструктуры, требований к RTO/RPO и опыта команды.