Налаштування автоматичного failover для 1С-Бітрікс

Primary-сервер бази даних впав о 3 годині ночі. Черговий інженер недоступний. Без автоматичного failover сайт лежатиме до ранку. З правильно налаштованим failover — через 30–60 секунд трафік переключиться на репліку, і користувачі нічого не помітять. Ми налаштовуємо failover під ключ з урахуванням усіх рівнів — від бази до конфігурації Бітрікс. За 2–3 дні ваш кластер отримає промисловий рівень відмовостійкості. З нами працюють компанії з навантаженням від 10 000 відвідувачів на добу — понад 50 проєктів. Оцініть економію: простий сайту з відвідуваністю 10 000 на добу обходиться в 50 000–100 000 гривень за годину простою. Failover окупається за один інцидент.

Компоненти автоматичного failover

Автоматичний failover для Бітрікс складається з трьох незалежних рівнів, які мають працювати узгоджено:

Якщо failover БД не супроводжується оновленням конфігу додатка, Бітрікс видаватиме помилки підключення.

Чому Patroni — стандарт для PostgreSQL failover?

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.

Порівняння Patroni та Orchestrator:

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) перевіряються окремо.

Для memcached/Redis проблем з кешем немає. Для файлового кешу — інвалідуємо через BXClearCache(true) або через адміністративну частину. У наше налаштування входить post-failover hook, який робить це автоматично.

Інша проблема — незафіксовані транзакції на момент падіння 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 зростає.

Кроки налаштування failover для Бітрікс

1. Аудит поточної схеми реплікації та інфраструктури.
2. Встановлення та налаштування Patroni (PostgreSQL) або Orchestrator (MySQL) з DCS (etcd/Consul).
3. Налаштування HAProxy з health-check через Patroni REST API.
4. Зміна підключення Бітрікс через HAProxy (не напряму до IP БД).
5. Написання hook-скрипту post-failover для інвалідації кешу та сповіщення.
6. Налаштування моніторингу LAG реплікації з алертом при перевищенні порогу.
7. Тестування failover на навантажувальному стенді з імітацією відмови.
8. Документація та навчання чергової зміни.

#!/bin/bash # post_failover.sh # Очищення файлового кешу Бітрікс bx-site /path/to/site bx:clear_cache --full # Сповіщення в Telegram або Slack curl -X POST -H "Content-Type: application/json" -d '{"text":"Failover completed"}' https://hooks.slack.com/...