На пике нагрузки — распродажа или запуск рекламной кампании — база данных Битрикс не справляется с SELECT-запросами. Страница каталога открывается 10 секунд, менеджеры не могут загрузить список заказов. Решение — репликация MySQL: мастер принимает запись, реплики отдают чтение. Без репликации база данных — единственная точка отказа всего проекта. Мы настраиваем отказоустойчивую репликацию с гарантией результата. Наш опыт — более 5 лет и 50 успешных проектов. Экономия на инфраструктуре после внедрения достигает 30% за счёт снижения нагрузки на мастер. Средний чек на поддержку падает на 40%. По нашим данным, на проектах с посещаемостью от 10 тысяч уникальных посетителей в день время ответа MySQL при пиковых нагрузках возрастает в 3–5 раз. Репликация снижает время загрузки страниц каталога на 40–60% и полностью исключает простои при бэкапах. Свяжитесь с нами для предварительной оценки вашего проекта.
Проблемы, которые решает репликация
- Read scaling: SELECT-запросы каталога, поиска, листингов выполняются на репликах. Нагрузка на мастер снижается на 70–90%.
- Резервное копирование без нагрузки: mysqldump с реплики не блокирует мастер. Даже при терабайтных базах.
- Failover: при аварии мастера реплика превращается в мастер за минуты. Простой — не более 5 минут при ручном переключении.
Настройка репликации для Битрикс
Настройка мастера
/etc/mysql/conf.d/master.cnf:
[mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW binlog_row_image = MINIMAL expire_logs_days = 7 max_binlog_size = 100M gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 binlog_format = ROW — построчная репликация. Надёжнее, чем STATEMENT для Битрикс, где встречаются недетерминированные функции (NOW(), RAND()).
binlog_row_image = MINIMAL — в binlog записываются только изменённые колонки. Уменьшает объём binlog на 60–80% для широких таблиц Битрикс.
Создайте пользователя репликации: GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.0.0.%' IDENTIFIED BY 'strong_password'.
Настройка реплики
/etc/mysql/conf.d/replica.cnf:
[mysqld] server-id = 2 relay_log = /var/log/mysql/mysql-relay-bin.log log_bin = /var/log/mysql/mysql-bin.log log_slave_updates = ON gtid_mode = ON enforce_gtid_consistency = ON read_only = ON super_read_only = ON slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 4 super_read_only = ON — запрещает запись даже пользователям с SUPER-привилегией. Предотвращает случайную запись, которая сломает репликацию.
Инициализация репликации с GTID: mysqldump --single-transaction --master-data=2 --gtid, затем дамп загружается на реплику. Запуск репликации:
CHANGE MASTER TO MASTER_HOST = '10.0.0.10', MASTER_USER = 'replicator', MASTER_PASSWORD = 'strong_password', MASTER_AUTO_POSITION = 1; START SLAVE; SHOW SLAVE STATUS\G Проверяем Slave_IO_Running: Yes, Slave_SQL_Running: Yes, Seconds_Behind_Master: 0.
Подключение Битрикс к реплике
Настройка через модуль кластера или вручную в /bitrix/.settings.php:
'connections' => [ 'value' => [ 'default' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => '10.0.0.10', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'pass', ], 'replica' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => '10.0.0.11', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'pass_ro', 'options' => ['slave' => true], ], ], ], Компоненты каталога, поиска и листинга направляют SELECT на реплику. Корзина, заказы, авторизация — всегда на мастер.
Как выбрать тип репликации?
Сравнение асинхронной, полусинхронной и синхронной репликации:
| Параметр | Асинхронная (GTID) | Полусинхронная | Синхронная (Galera) |
|---|---|---|---|
| Задержка на запись | Минимальная | +10-30% | +50-100% |
| Риск потери данных | Есть (при сбое мастера) | Минимальный | Нулевой |
| Производительность | Высокая | Средняя | Низкая на запись |
| Совместимость с Битрикс | Полная | Полная | Требует доработок |
Для 95% проектов на Битрикс достаточно асинхронной репликации с GTID. Полусинхронная — если критична потеря ни одной транзакции (интернет-магазины с оплатами).
Когда нужен автоматический failover?
Если время простоя сайта критично (более 5 минут недопустимо), настройте автоматический failover через Orchestrator или ProxySQL. Эти инструменты мониторят состояние мастера и реплик, при сбое автоматически промотируют реплику и перенаправляют трафик. Время восстановления сокращается до секунд. Закажите настройку failover вместе с репликацией.
Мониторинг репликации
Статус проверяется запросом SHOW SLAVE STATUS\G. Ключевой параметр — Seconds_Behind_Master. При задержке более 30 секунд возможны устаревшие данные. Причины: тяжёлые транзакции, недостаток параллельных воркеров, I/O-узкое место.
Подробнее о мониторинге
Для автоматического мониторинга используйте скрипты с проверкой Seconds_Behind_Master каждые 5 минут. Также полезно отслеживать Slave_IO_Running и Slave_SQL_Running. При отклонениях — уведомление в Telegram или почту.
Пошаговая инструкция по настройке репликации
- Настройте мастер (server-id, binlog, GTID).
- Настройте реплику (server-id, relay log, read_only, параллельная репликация).
- Создайте пользователя репликации с правами REPLICATION SLAVE.
- Выполните консистентный дамп мастера с GTID-позицией.
- Загрузите дамп на реплику.
- Запустите репликацию командой CHANGE MASTER и START SLAVE.
- Проверьте статус (Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master).
- Настройте подключение Битрикс к реплике.
- Настройте мониторинг и, при необходимости, автоматический failover.
- Проведите нагрузочное тестирование.
Выполнение failover при отказе мастера
Ручной failover: промоутируйте реплику в мастер.
STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only = OFF; SET GLOBAL super_read_only = OFF; Измените host в .settings.php на IP новой мастер-ноды.
GTID (глобальные идентификаторы транзакций) упрощают переключение — не нужно искать позицию binlog. Подробнее в документации MySQL и Wikipedia: GTID.
Процесс работы по настройке репликации
| Этап | Длительность | Что делаем |
|---|---|---|
| Анализ | 2-4 часа | Изучаем профиль запросов, выявляем узкие места |
| Проектирование | 1-2 часа | Выбираем топологию, количество реплик |
| Конфигурация | 2-4 часа | Настраиваем master, replica, сетевые параметры |
| Перенос данных | 1-2 часа | Создаем консистентный дамп без остановки сайта |
| Тестирование | 2-4 часа | Проверяем репликацию, failover, нагрузку |
| Деплой | 1-2 часа | Подключаем Битрикс, включаем мониторинг |
Что входит в работу
- Конфигурация master.cnf и replica.cnf с учётом вашего оборудования.
- Создание пользователей репликации с ограниченными правами.
- Перенос данных с мастера на реплику без даунтайма.
- Настройка подключения Битрикс (модуль кластера или .settings.php).
- Мониторинг (задержка, ошибки, статус).
- Документация: схема топологии, инструкция по failover, скрипты мониторинга.
- Обучение: как проверять статус и действия при ошибках.
- Поддержка: 2 недели после релиза.
Сроки: от 1 до 3 дней в зависимости от сложности. Стоимость рассчитывается индивидуально — свяжитесь с нами, оценим ваш проект за 1 день. Получите консультацию по настройке репликации и отказоустойчивый Битрикс.