Налаштування автоматичного failover для 1С-Bitrix
Primary-сервер бази даних упав о 3 годинах ночі. Дежурний інженер недоступний. Без автоматичного failover сайт буде лежати до ранку. З правильно налаштованим failover — через 30–60 секунд трафік переключиться на реплику, та користувачі нічого не помітять.
Компоненти автоматичного failover
Автоматичний failover для Bitrix складається з трьох незалежних шарів:
1. Failover БД — переключення з primary на replica при падінні primary. 2. Failover веб-сервера — балансувальник виводить недоступний вузол з ротації. 3. Оновлення конфігурації Bitrix — переключення рядка підключення на новий 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 секунд.
Критично важливо для Bitrix: програма підключається до БД не напрямо до 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-інсталяцій Bitrix аналог Patroni — Orchestrator. Він стежить за топологією репліцирування, виявляє падіння master та автоматично промотує найбільш актуальну replica.
Після промоції Orchestrator викликає hook-скрипт, який оновлює DNS або notify-скрипт для HAProxy.
Налаштування Bitrix для роботи з репліцею
При failover новий primary — це бувша read-replica. До failover Bitrix міг бути налаштований на розділення 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
Після переключення Bitrix може утримувати застарілі дані в кеші, якщо кеш був налаштований з привязкою до 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
- Підключення Bitrix через HAProxy, а не напрямо до IP БД
- Hook-скрипт post-failover для інвалідації кешу та сповіщення
- Моніторинг LAG репліцирування з алертом при перевищенні порога
- Регулярне тестування failover на навантажувальному стенді