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

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

Сроки и стоимость

Типовой проект на кластере из двух серверов занимает 2–3 рабочих дня. Сложность возрастает при наличии шардинга, кастомных настроек репликации или специфичных конфигов Битрикс. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим вашу инфраструктуру бесплатно. Свяжитесь с нами для аудита вашего проекта.

Patroni: https://github.com/zalando/patroni Orchestrator: https://github.com/openark/orchestrator

Что включает профессиональная установка 1С-Битрикс

Мы начинаем установку 1С-Битрикс с проверки innodb_buffer_pool_size. Дефолтное значение MySQL (128 МБ) — приговор для интернет-магазина с каталогом на 10 000+ товаров. Мы ставим 70–80% от доступной RAM на выделенном сервере, 50% на VPS. Одна эта настройка ускоряет сайт в 2–3 раза по сравнению с дефолтом. Оценим ваш проект за один день — получите консультацию. Обращайтесь, чтобы заказать установку под ключ с гарантией производительности.

Как выбрать хостинг и редакцию для установки 1С-Битрикс?

BitrixVM — виртуальная машина с предустановленным стеком: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push‑сервер. Для VPS — лучший старт. Всё уже сконфигурировано под Битрикс, включая OPcache, логротацию и firewall. Управление через веб‑панель на порту 8890.

VPS/VDS — золотая середина. Минимальная конфигурация для среднего интернет‑магазина: 2 vCPU, 4 ГБ RAM, SSD. Оптимальная: 4 vCPU, 8 ГБ RAM. ОС: Ubuntu 22.04 или Debian 12. Если не BitrixVM — настраиваем стек вручную под задачу. Виртуальный хостинг — только для визиток и лендингов. Требования: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 МБ RAM, .htaccess. Хостинг‑партнёры 1С-Битрикс — гарантия совместимости. Выделенный сервер — для highload. Типичная архитектура: веб‑сервер отдельно, база данных отдельно, Redis/Memcached отдельно. На редакции «Энтерпрайз» — веб‑кластер с балансировщиком. Облако (Yandex Cloud, VK Cloud, Selectel) — когда нагрузка скачет: распродажи, сезонные пики. Автомасштабирование через Managed Kubernetes или просто вертикальное масштабирование VM.

Выбор редакции — не менее важный шаг. Частая ошибка: берут «Малый бизнес» для магазина, который через полгода вырастает до B2B с оптовыми ценами и тремя складами. Переход на «Бизнес» — доплата разницы, данные не теряются, но лучше предусмотреть заранее. Наши специалисты подберут редакцию под текущие задачи и с запасом на рост. Например, лицензия «Бизнес» (около 35 000 ₽) окупается за счёт мультисклада и обмена с 1С, а неправильный выбор приводит к потере до 30 000 ₽ ежемесячно на избыточных ресурсах.

Какие настройки сервера критичны для 1С-Битрикс?

Веб‑сервер и PHP

nginx как reverse proxy + Apache (mod_php) или nginx + PHP-FPM напрямую. Второй вариант экономит память — Apache не нужен. Но некоторые модули Битрикс используют .htaccess, поэтому для совместимости иногда оставляем Apache. Конфигурация nginx: fastcgi_read_timeout 300 — для долгих операций (импорт из 1С), client_max_body_size 1024m — загрузка больших файлов. Закрываем доступ к .settings.php, .settings_extra.php, bitrix/.settings.php — там пароли к базе. Rewrite‑правила из urlrewrite.php — Битрикс сам генерирует, но при nginx + PHP-FPM нужно продублировать. PHP 8.0–8.2 с расширениями: mbstring, curl, gd, xml, json, opcache, redis/memcached. Ключевые настройки php.ini: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M.

База данных и кэширование

MySQL/MariaDB. Ключевые параметры my.cnf: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — по количеству ядер CPU. Кодировка utf8mb4 обязательно, иначе эмодзи и спецсимволы ломаются. Redis предпочтительнее Memcached для Битрикс — поддерживает persistent connections и более надёжен. Настраиваем в .settings_extra.php:

'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]

SSL, почта и cron

SSL — Let's Encrypt через certbot в 90% случаев. Редирект HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. В Битрикс переключаем на HTTPS в настройках главного модуля. Почта: отказываемся от mail() — подключаем SMTP (Яндекс.Почта для домена, Mail.ru для бизнеса). Обязательно настраиваем SPF, DKIM, DMARC. Без SPF письма уходят в спам. Тестируем доставляемость через mail‑tester.com — оценка 9+/10. Cron: агенты Битрикс переводим на системный cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. На cron вешаем обмен с 1С (15–60 мин), поисковую переиндексацию, бэкапы (mysqldump + rsync, ротация 7+4), очистку временных файлов.

Безопасность и администрирование

Файловая система: владелец www-data, директории 755, файлы 644, upload 775. nginx блокирует доступ к файлам конфигурации. Включаем Проактивную защиту Битрикс — WAF, контроль активности (блокировка после 5 неудачных попыток), проверку целостности ядра. Для админ‑панели: двухфакторная аутентификация через Google Authenticator или OTP, ограничение доступа по IP через nginx для параноиков.

Сколько времени занимает установка 1С-Битрикс и настройка?

Проверка после установки (пошаговый чек‑лист)

1. Монитор производительности (/bitrix/admin/perfmon_panel.php) — целимся в 30+ баллов. Ниже 20 — есть серьёзные проблемы с конфигурацией.
2. Проверка системы — автоматическая проверка всех параметров. Красные пункты — исправляем обязательно, жёлтые — по ситуации.
3. Сканер безопасности — проверка на типичные уязвимости.
4. PageSpeed Insights — TTFB < 200мс на VPS, LCP < 2.5с.
5. Тестовый обмен с 1С — если планируется интеграция, проверяем CommerceML‑обмен до запуска.

Дополнительно проверяем версии ПО, настройки кэширования, работу cron, SSL‑сертификат, SPF/DKIM/DMARC, права доступа, удаление дефолтных пользователей и страниц. Для проектов с 54‑ФЗ убеждаемся, что настроена фискализация через ОФД‑провайдера.

Что входит в работу (deliverables)

• Полностью настроенный сервер под 1С-Битрикс с оптимизацией MySQL, PHP, nginx.
• Установленная и активированная лицензия нужной редакции.
• SSL‑сертификат, почтовые настройки, cron и бэкапы.
• Документация: все параметры конфигурации, доступы, cron‑задачи.
• Обучение контент‑менеджера: как заходить в админку, добавлять товары, загружать изображения.
• Поддержка после установки в течение 30 дней — консультации по настройкам.

Почему стоит доверить установку профессионалам?

Неправильная установка — потеря времени и денег. Мы видели проекты, где магазин на «Старте» не мог выдержать 50 посетителей, потому что не был настроен innodb_buffer_pool_size. После переноса на VPS с правильной конфигурацией сайт «полетел». Неправильная конфигурация может обходиться в 30 000 ₽ ежемесячно из‑за избыточного потребления ресурсов. Вы получаете готовую архитектуру, которая масштабируется. Закажите установку 1С-Битрикс под ключ — и получите надёжную платформу для роста бизнеса. Свяжитесь с нами — рассчитаем стоимость под ваш проект. Опыт более 7 лет, реализовано 120+ проектов на Битрикс, включая highload‑магазины с миллионными каталогами. Обращайтесь — мы поможем настроить Битрикс под ваш проект.