Як організувати резервний дата-центр для 1С-Бітрікс з нульовим RPO
Допустимо, ваш інтернет-магазин на Бітрікс приносить 100 замовлень на годину. В пік навантаження основний сервер виходить з ладу через збій дискового масиву. Без резервного ДЦ ви втрачаєте кожне замовлення до підйому дампу — це години простою та мільйонні збитки. Навіть якщо є бекап, його розгортання займає 2-3 години, а дані за останні години зникають. Ми налаштовуємо резервний дата-центр, який перехоплює трафік за хвилини, а втрати даних не перевищують секунди. Використовуємо перевірені техніки: GTID-реплікацію MySQL, безперервну синхронізацію файлів та автоматичний failover DNS. Наш досвід — 50+ проєктів від інтернет-магазинів до корпоративних порталів. Кожен випадок унікальний, але ми виробили стандартний підхід, який гарантує RPO < 1 хвилини та RTO < 5 хвилин.
Чому звичайний бекап не підходить?
Резервне копіювання не гарантує швидкого відновлення, а копія на тому ж диску марна при пожежі в ДЦ. Справжня відмовостійкість вимагає активної реплікації бази та синхронізації файлів на другу площадку. Наш стек — Percona Server 8.0, Lsyncd, Ansible — перевірений на 50+ проєктах.
Як налаштувати резервний ДЦ для 1С-Бітрікс?
Є три критичні компоненти: реплікація MySQL/MariaDB, синхронізація файлів та автоматичний failover DNS. Розберемо кожен.
Реплікація бази даних
Використовуємо GTID-реплікацію — вона простіша в обслуговуванні та виключає розсинхрон при зміні майстра. GTID автоматично відстежує всі транзакції, тому при promote репліки не потрібно шукати позицію в логах. Конфіг репліки:
[mysqld] server-id = 10 gtid_mode = ON enforce_gtid_consistency = ON read_only = ON log_slave_updates = ON Для моніторингу використовуємо Prometheus + mysqld_exporter. Лаг реплікації в секундах: Seconds_Behind_Master. Якщо бачите 300 — проблема з мережею або навантаженням.
Синхронізація файлів
Каталог upload/ синхронізуємо безперервно через inotifywait + rsync. Цей тандем ловить кожну зміну (create, modify, delete) і миттєво передає diff на резервну площадку. Приклад скрипта:
inotifywait -m -r -e create,modify,delete /var/www/bitrix/upload/ | while read path action file; do rsync -az /var/www/bitrix/upload/ backup-dc:/var/www/bitrix/upload/ & done Для великих проєктів з тисячами файлів краще використовувати Lsyncd — він агрегує події та знижує навантаження на мережу. А ось конфіги (bitrix/.settings.php, dbconn.php) зберігаємо в Git і розгортаємо через Ansible. Це дає версіонування та швидкий відкат.
Готовий веб-стек на резервній площадці
На другому сервері мають стояти nginx, php-fpm, Redis з тими ж версіями. Файли ядра Бітрікс (bitrix/, local/) копіюємо раз на добу або після кожного деплою. Це прискорює активацію — не потрібно качати гігабайти в момент аварії.
Що краще: ручне перемикання чи автоматичний failover?
Порівняємо в таблиці:
| Критерій | Ручне перемикання | Автоматичний failover |
|---|---|---|
| Час реакції | 15-60 хвилин | 1-2 хвилини |
| Ризик помилки | Високий (людський фактор) | Низький (скрипти перевірені) |
| TTL DNS | 60-300 секунд (можна знизити) | 60 секунд (обов'язково) |
| Вартість налаштування | Нижча (тільки скрипт) | Вища (плюс моніторинг) |
Автоматичний failover знижує час відновлення в 10 разів порівняно з ручним. Приклад healthcheck-скрипта для Cloudflare:
#!/bin/bash MAIN_IP="185.10.1.100" BACKUP_IP="195.20.2.100" DOMAIN="your-site.ru" if ! curl -sf --max-time 10 "https://$DOMAIN/health" > /dev/null; then curl -X PATCH \ "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \ -H "Authorization: Bearer $CF_TOKEN" \ -H "Content-Type: application/json" \ --data '{"content":"'"$BACKUP_IP"'","ttl":60}' fi Як автоматизувати перемикання через Ansible?
Коли failover спрацював, на резервній площадці потрібно виконати послідовність дій?
Без автоматизації кожен крок вручну — втрата часу та ризик помилки. Ми використовуємо Ansible playbook, який за хвилину:
- Піднімає репліку до майстра:
STOP SLAVE; RESET SLAVE ALL; - Оновлює
bitrix/.settings.php— замінює IP БД на127.0.0.1 - Переконується, що Redis запущений, сесії доступні
- Перевіряє агенти на сторінці
/bitrix/admin/agent_list.php - Виконує тестове замовлення
- Повідомляє команду через Telegram/Slack
Приклад playbook:
- name: Promote MySQL replica to master mysql_replication: mode: stopreplica - name: Update Bitrix DB config template: src: settings.php.j2 dest: /var/www/bitrix/bitrix/.settings.php vars: db_host: "127.0.0.1" - name: Restart php-fpm service: name: php8.1-fpm state: restarted Порівняння інструментів синхронізації
| Інструмент | Швидкість | Навантаження на IO | Підходить для |
|---|---|---|---|
| rsync + inotify | Висока | Середня | Маленькі каталоги (< 50 тис. файлів) |
| Lsyncd | Середня | Низька | Великі каталоги з частими змінами |
| Unison | Низька | Низька | Двостороння синхронізація |
Для upload/ рекомендуємо Lsyncd, якщо файлів більше 50 000.
Що входить у налаштування резервного ДЦ під ключ
- Аудит поточної інфраструктури
- Налаштування GTID-реплікації MySQL/MariaDB
- Встановлення та конфігурація Lsyncd/rsync для синхронізації файлів
- Налаштування healthcheck-скрипта та автоматичного оновлення DNS
- Ansible playbook для failover
- Документація щодо процедури перемикання
- Навчання вашої команди (1 година, онлайн)
- Тестове перемикання з вимірами RPO та RTO
Терміни налаштування
Від 5 до 8 робочих днів, включаючи тестування. Вартість розраховується індивідуально — залежить від обсягу даних, кількості серверів та складності інтеграцій.
Хочете такий же рівень захисту? Отримайте консультацію — наші інженери безкоштовно оцінять ваш проєкт. Ми спеціалізуємося на Бітрікс більше десяти років, реалізували 50+ відмовостійких рішень. Надаємо гарантію на виконані роботи.