Настройка HA для БД: отказоустойчивые кластеры и фейловер

Представьте ситуацию: в разгар рабочего дня ваш основной сервер базы данных «падает». Не зависает, а именно падает - питание уходит, диск выходит из строя или ядро Linux паникует. Что происходит дальше? Если у вас нет настроенной высокой доступности (High Availability, HA), то бизнес стоит. Клиенты видят ошибку 503, менеджеры не могут выставить счета, а вы получаете гневные звонки от руководства. Настройка HA для баз данных - это не просто «хорошая практика», это страховка вашего бизнеса от простоев.

Многие ошибочно путают высокую доступность с бэкапами. Бэкап спасет ваши данные, если они удалились или повредились логически. Но он не вернет систему в работу за секунды, если сервер физически умер. Именно здесь на сцену выходят отказоустойчивые кластеры и механизмы автоматического переключения (фейловера). В этой статье мы разберем, как это работает под капотом, какие инструменты выбрать и как избежать классических ошибок при настройке.

Чем HA отличается от резервного копирования?

Давайте сразу расставим точки над «i». Резервное копирование (backup) - это процесс создания копии данных для восстановления в будущем. Высокая доступность (HA) - это способность системы продолжать работу даже при частичных отказах оборудования.

• Бэкап: Вы теряете данные с момента последнего снимка (RPO > 0). Восстановление занимает минуты или часы (RTO велик).
• HA-кластер: Данные синхронизируются почти мгновенно (RPO ≈ 0). Переключение на живой узел происходит автоматически за секунды (RTO мал).

В идеальном мире вам нужны оба инструмента. Но если бюджет ограничен, HA часто важнее для непрерывности бизнеса, чем частота бэкапов, потому что простой стоит дороже, чем потеря пары минут транзакций.

Как работают современные механизмы репликации?

Сердце любого HA-решения для СУБД - это репликация. Чтобы второй сервер мог принять нагрузку, когда первый упал, он должен иметь те же данные. Здесь есть два основных подхода, и выбор между ними критичен для целостности данных.

Первый подход - асинхронная репликация. Это стандарт по умолчанию во многих системах, например, в MySQL или PostgreSQL в базовой конфигурации. Мастер пишет данные на диск и сразу отвечает клиенту: «Готово!». Затем он отправляет изменения репликам. Если мастер упадет до того, как данные уйдут на реплику, эти транзакции будут потеряны навсегда. Это быстро, но рискованно для финансовых операций.

Второй подход - синхронная репликация. Мастер ждет подтверждения от хотя бы одной реплики, что данные записаны в их журнал предзаписи (WAL). Только после этого он подтверждает запись клиенту. Гарантий потерь нет, но производительность падает. Задержка сети (latency) становится вашим врагом. Если сеть между дата-центрами нестабильна, синхронный режим может превратить вашу базу в черепаху.

Для большинства проектов оптимумом является полу-синхронная репликация или использование нескольких синхронных реплик, чтобы один медленный узел не блокировал всю систему.

Инструменты выбора: от Postgres до MySQL

Не существует универсального молотка для всех гвоздей. Выбор ПО зависит от вашей СУБД и бюджета. Разберем популярные связки.

Если вы используете PostgreSQL, забудьте про ручные скрипты cron. Берите Patroni. Он управляет жизненным циклом кластера, следит за состоянием нод через распределенный хранилище ключей (обычно etcd) и сам решает, кто главный. Для MySQL Percona XtraDB Cluster (PXC) хорош своей простотой, но помните: мульти-мастерство создает проблемы с автоинкрементами и конфликтами записи.

Проблема мозгового штурма и роль кворума

Что будет, если сеть разделится на две части? Например, в одном ЦОДе живут 1 мастер и 1 реплика, а в другом - только одна реплика. Сеть между ними пропадает. Кто станет мастером? Если обе стороны решат, что они главные, начнется хаос: данные разойдутся, и объединить их обратно будет болью.

Эту проблему называют «split-brain» (расщепление мозга). Решается она через механизм кворума. Кворум - это большинство голосов. В кластере из 3 узлов нужно минимум 2 живых узла, чтобы система работала. Если остается 1, он становится «читаемым» или полностью останавливается, чтобы не допустить записи.

Поэтому золотое правило HA: всегда используйте нечетное количество узлов (3, 5, 7). Два узла без третьего арбитра (witness node) - это риск. Если один умрет, второй не сможет принять решение об изоляции первого, так как не наберет большинство.

Фейловер: автоматика против человека

Переключение (failover) бывает двух видов: автоматическое и ручное. Автоматический фейловер включается, когда монитор (например, Patroni или Orchestrator) видит, что мастер не отвечает на heartbeat-запросы более N секунд. Система сама поднимает реплику, переназначает IP-адрес (VIP) или DNS-запись и уведомляет приложение.

Звучит идеально, но есть нюанс. Ложноположительные срабатывания случаются чаще, чем кажется. Сервер может быть загружен на 100% CPU и не отвечать на пинги, но при этом нормально обрабатывать SQL-запросы. Если автоматика убьет его и переведет нагрузку на другую машину, которая тоже не готова, вы получите двойную аварию.

Практический совет: настройте агрессивные таймауты для обнаружения смерти (чтобы быстро заметить реальную проблему), но консервативные пороги для самого переключения. Также обязательно добавьте алерты в Telegram или Slack перед тем, как произойдет фейловер. Иногда лучше подождать 30 секунд и проверить логи, чем сломать стабильную систему из-за кратковременного скачка нагрузки.

Проверяем готовность: чек-лист перед боем

Вы настроили кластер, запустили сервисы. Поздравляю, теперь можно спать спокойно? Нет. Пока вы не убили мастер вручную, вы не знаете, работает ли ваша HA.

• Тест на выживание: Остановите сервис postgresql на мастере (systemctl stop postgresql). Проверьте, поднялся ли новый мастер. Проверьте, доступны ли данные через VIP.
• Проверка сети: Обрыв кабеля между узлами. Убедитесь, что кворум сохранился и старые узлы перешли в read-only режим, а не продолжают писать друг другу.
• Проверка приложения: Ваше приложение должно корректно отрабатывать ошибки соединения и переподключаться. Если код жестко привязан к IP мастера, никакой HA не поможет. Используйте пул коннекторов (PgBouncer, ProxySQL).
• Резервный канал связи: Есть ли отдельная сеть для управления кластером? Если управление идет по той же сети, где идут пользовательские запросы, перегрузка сети может вызвать ложный фейловер.

Не забывайте про мониторинг. Метрики вроде lag_in_bytes (разница в логах между мастером и репликой) должны быть нулевыми или близкими к нулю. Если лаг растет, значит, реплика не успевает применять изменения. При фейловере вы можете потерять данные, которые еще не были реплицированы.

Частые ошибки новичков

За годы практики в Ростовской области и удаленно я видел одни и те же грабли, на которые наступают системные администраторы.

Первая ошибка - игнорирование дисковой подсистемы. Если у вас RAID-контроллер с батарейкой (BBU) вышел из строя, а контроллер перешел в write-through режим, скорость записи упадет в разы. Реплика отстанет, кворум может развалиться. HA не спасает от медленных дисков.

Вторая ошибка - одинаковые конфигурации файлов. Конфиги postgresql.conf или my.cnf должны быть идентичны на всех узлах. Однажды я чинил кластер, где на мастере было включено fsync=on, а на реплике случайно оставили off. При фейловере новая главная машина начала терять данные при сбоях питания.

Третья ошибка - отсутствие документации по восстановлению. Когда все горит, никто не помнит, какой командой менять роль узла. Держите Runbook (памятку действий) под рукой.