Настройка автоматического failover для 1С-Битрикс

Primary-сервер базы данных упал в 3 часа ночи. Дежурный инженер недоступен. Без автоматического failover сайт будет лежать до утра. С правильно настроенным failover — через 30–60 секунд трафик переключится на реплику, и пользователи ничего не заметят. Мы настраиваем failover под ключ с учётом всех слоёв — от базы до конфигурации Битрикс. За 2–3 дня ваш кластер получит промышленный уровень отказоустойчивости. С нами работают компании с нагрузкой от 10 000 посетителей в сутки — более 50 проектов за последние 5 лет. Оцените экономию: простой сайта с посещаемостью 10 000 в сутки обходится в $500–1k за час простоя. 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/...