Настройка автоматического failover для 1С-Битрикс
Primary-сервер базы данных упал в 3 часа ночи. Дежурный инженер недоступен. Без автоматического failover сайт будет лежать до утра. С правильно настроенным failover — через 30–60 секунд трафик переключится на реплику, и пользователи ничего не заметят.
Компоненты автоматического failover
Автоматический failover для Битрикс состоит из трёх независимых слоёв:
1. Failover БД — переключение с primary на replica при падении primary. 2. Failover веб-сервера — балансировщик выводит недоступный узел из ротации. 3. Обновление конфигурации Битрикс — переключение строки подключения на новый master.
Все три должны работать согласованно, иначе failover БД без обновления конфига приложения даст ошибки подключения.
Failover PostgreSQL через Patroni
Patroni — де-факто стандарт для автоматического failover PostgreSQL. Архитектура: Patroni-агент на каждом узле, etcd/Consul как DCS (distributed configuration store), HAProxy или pgBouncer перед кластером.
Patroni следит за состоянием узлов и при недоступности primary проводит выборы нового лидера через DCS. Реплика с минимальным отставанием (наименьшим LSN lag) становится новым primary. Весь процесс занимает 10–30 секунд.
Критически важно для Битрикс: приложение подключается к БД не напрямую к IP-серверу, а через HAProxy или через виртуальный IP (VIP), управляемый Patroni:
# /bitrix/.settings.php — подключение через HAProxy
'dsn' => 'pgsql:host=haproxy.internal;port=5432;dbname=bitrix',
HAProxy проверяет Patroni REST API (http://patroni-node:8008/master) и направляет трафик только на текущий primary.
Failover MySQL через Orchestrator
Для MySQL-инсталляций Битрикс аналог Patroni — Orchestrator. Он отслеживает топологию репликации, обнаруживает падение master и автоматически промотирует наиболее актуальную replica.
После промоции Orchestrator вызывает hook-скрипт, который обновляет DNS или notify-скрипт для HAProxy.
Настройка Битрикс для работы с репликой
При failover новый primary — это бывшая read-replica. До failover Битрикс мог быть настроен на разделение read/write:
// /bitrix/.settings.php
'connections' => [
'default' => [
'host' => 'primary.db',
'port' => '5432',
// ... write-соединение
],
'replica' => [
'host' => 'replica.db',
'port' => '5432',
'readonly' => true,
// ... read-соединение
],
],
После failover replica стала primary — строка replica больше не должна использоваться для read-only соединения (она теперь принимает и write). HAProxy с проверкой Patroni API решает это автоматически: оба порта (write 5432, read 5433) проверяются отдельно.
Проверка после failover
После переключения Битрикс может держать устаревшие данные в кеше, если кеш был настроен с привязкой к old primary. Для memcached/Redis — проблем нет. Для файлового кеша: инвалидируем через BXClearCache(true) или через административную часть.
Другая проблема — незафиксированные транзакции на момент падения primary. WAL-репликация гарантирует применение всех записанных транзакций на replica, но транзакции, находившиеся в памяти primary в момент краша, теряются. Это нормальное поведение синхронной/асинхронной репликации с потерями в секунды.
Мониторинг состояния
# Patroni — текущий лидер
curl http://patroni-node1:8008/cluster | jq '.members[] | {name, role, lag}'
# Задержка репликации (PostgreSQL)
SELECT
client_addr,
pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
FROM pg_stat_replication;
Алерт: если lag_bytes > 50MB — репликация не успевает, риск потери данных при failover возрастает.
Что настраиваем
- Patroni (PostgreSQL) или Orchestrator (MySQL) на кластере БД
- HAProxy с health-check через Patroni REST API
- Подключение Битрикс через HAProxy, а не напрямую к IP БД
- Hook-скрипт post-failover для инвалидации кеша и уведомления
- Мониторинг LAG репликации с алертом при превышении порога
- Регулярное тестирование failover на нагрузочном стенде