Репликация MySQL для Битрикс: ускорение и отказоустойчивость

На пике нагрузки — распродажа или запуск рекламной кампании — база данных Битрикс не справляется с 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 на реплику. Корзина, заказы, авторизация — всегда на мастер.

Как выбрать тип репликации?

Сравнение асинхронной, полусинхронной и синхронной репликации:

Для 95% проектов на Битрикс достаточно асинхронной репликации с GTID. Полусинхронная — если критична потеря ни одной транзакции (интернет-магазины с оплатами).

Когда нужен автоматический failover?

Если время простоя сайта критично (более 5 минут недопустимо), настройте автоматический failover через Orchestrator или ProxySQL. Эти инструменты мониторят состояние мастера и реплик, при сбое автоматически промотируют реплику и перенаправляют трафик. Время восстановления сокращается до секунд. Закажите настройку failover вместе с репликацией.

Мониторинг репликации

Статус проверяется запросом SHOW SLAVE STATUS\G. Ключевой параметр — Seconds_Behind_Master. При задержке более 30 секунд возможны устаревшие данные. Причины: тяжёлые транзакции, недостаток параллельных воркеров, I/O-узкое место.

Пошаговая инструкция по настройке репликации

1. Настройте мастер (server-id, binlog, GTID).
2. Настройте реплику (server-id, relay log, read_only, параллельная репликация).
3. Создайте пользователя репликации с правами REPLICATION SLAVE.
4. Выполните консистентный дамп мастера с GTID-позицией.
5. Загрузите дамп на реплику.
6. Запустите репликацию командой CHANGE MASTER и START SLAVE.
7. Проверьте статус (Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master).
8. Настройте подключение Битрикс к реплике.
9. Настройте мониторинг и, при необходимости, автоматический failover.
10. Проведите нагрузочное тестирование.

Выполнение 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.

Процесс работы по настройке репликации

Что входит в работу

• Конфигурация master.cnf и replica.cnf с учётом вашего оборудования.
• Создание пользователей репликации с ограниченными правами.
• Перенос данных с мастера на реплику без даунтайма.
• Настройка подключения Битрикс (модуль кластера или .settings.php).
• Мониторинг (задержка, ошибки, статус).
• Документация: схема топологии, инструкция по failover, скрипты мониторинга.
• Обучение: как проверять статус и действия при ошибках.
• Поддержка: 2 недели после релиза.

Сроки: от 1 до 3 дней в зависимости от сложности. Стоимость рассчитывается индивидуально — свяжитесь с нами, оценим ваш проект за 1 день. Получите консультацию по настройке репликации и отказоустойчивый Битрикс.

Кластеризация 1С-Битрикс

Представьте: flash-распродажа, 10 000 пользователей одновременно заходят на сайт, сервер падает с 502, корзины пропадают, менеджеры звонят в поддержку. Мы видели это десятки раз. Решение — кластеризация: балансировка запросов между серверами, репликация базы данных и автоматическое переключение при сбое. Закажите аудит текущей инфраструктуры — за 2 дня определим, нужен ли кластер и какой. Наш опыт — 40+ высоконагруженных проектов на Битрикс.

Почему кластеризация 1С-Битрикс критична для отказоустойчивости?

80-90% запросов в типичном проекте — SELECT. Каталог, карточки, фильтры — всё чтение. Master-slave репликация отдаёт SELECT на slave-серверы, master остаётся только для записи. Модуль «Веб-кластер» (редакция «Бизнес» и выше) маршрутизирует запросы автоматически.

Настройка, где спотыкаются: на master binlog_format = ROW. STATEMENT-репликация на NOW() или UUID() даёт расхождения — потом неделя дебага. Уникальный server-id, включённый binary log. На slave — read_only = ON, relay-log. Инициализация через xtrabackup (не mysqldump, который блокирует таблицы на полчаса на базе в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Если slave отстаёт на 5+ секунд, покупатель оформляет заказ, возвращается в личный кабинет — а заказа нет (SELECT ушёл на отстающий slave). Модуль позволяет исключить критичные запросы из маршрутизации на slave вручную.

Failover: Orchestrator или ProxySQL промоутят slave в master за 15-30 секунд. Модуль поддерживает до 9 slave-соединений с настраиваемыми весами. Проверка целостности — pt-table-checksum из Percona Toolkit. Экономия на неэффективной инфраструктуре — до 40% бюджета, что в среднем составляет 300 000 рублей в год для проектов с 50 000+ уникальных посетителей. Подробнее о репликации — MySQL Replication Documentation и Wikipedia: Репликация базы данных.

Признаки, когда кластеризация необходима

Не каждому проекту. Конкретные маркеры:

• 50 000-100 000 уников в сутки — один сервер начинает отдавать 502 в часы пик
• Пиковые скачки в 5-10 раз (распродажи, flash-sale) — нагрузка растёт за минуты, вертикально не масштабируешься
• SLA 99.9% (не более 8.7 часов простоя в год) — с одним сервером недостижимо
• Географическая распределённость пользователей

Иногда хватает композитного кэша, оптимизации SQL и вертикального масштабирования. Мы честно скажем, если кластер пока не нужен. Инвестиции в кластеризацию окупаются за 3-6 месяцев при пиковых нагрузках. Средний бюджет проекта — от 150 000 рублей.

Архитектура — четыре уровня

Балансировщик. HAProxy, nginx upstream или облачный LB. Round-robin для равномерного распределения, ip-hash для привязки сессий, least connections для адаптивной балансировки. Health checks выводят мёртвые серверы из пула. SSL-терминация на балансировщике разгружает веб-ноды.

Веб-серверы. Идентичные nginx + php-fpm, каждая с полной копией кода. Сессии — в Redis/Memcached, не на диске (иначе при переключении между серверами пользователь теряет корзину). В облаке — автоскейлинг: нагрузка выросла — добавились серверы, упала — выключились.

Кэш. Redis Cluster с шардингом данных по узлам. Redis Sentinel для небольших кластеров. Memcached быстр, но без persistence. Конфигурация в .settings.php — серверы, веса, стратегия шардинга.

Файловое хранилище. Загрузки, картинки — доступны с каждой ноды. NFS для 2-3 серверов, но это единая точка отказа. GlusterFS — распределённая ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — вынос статики в объектное хранилище, модуль Битрикс работает из коробки.

Как обеспечить failover на каждом уровне кластера?

Кластер в 5 раз надёжнее одиночного сервера — при отказе любого узла сервис продолжает работать.

Типичные ошибки при настройке кластера

• Сессии на файлах — при отключении сервера пользователь теряет корзину и авторизацию.
• Не настроенный Seconds_Behind_Master — продажи падают, а SLA не выполняется.
• Одна точка отказа на уровне файлового хранилища (NFS без репликации).
• Отсутствие мониторинга репликации — расхождение данных остаётся незамеченным.

Мы включаем проверку всех этих точек в аудит и тестирование.

Процесс работы

1. Аудит нагрузки — профиль нагрузки, узкие места, нагрузочное тестирование. Находим потолок одиночного сервера.
2. Проектирование — компоненты под требования и бюджет. Не всем нужен GlusterFS — иногда хватит NFS и бэкапов.
3. Инфраструктура — серверы, сеть, файрволы. Ansible для автоматизации — любой узел можно пересоздать за минуты.
4. Миграция — перенос с минимальным простоем. Компоненты подключаются последовательно, каждый шаг с проверкой.
5. Тестирование — имитация пиковых условий. Роняем master, отключаем веб-сервер, убиваем Redis — смотрим, как система себя ведёт.
6. Документация — схема архитектуры, runbook, планы аварийного восстановления.

Что входит в работу по кластеризации?

Сроки

Свяжитесь с нами — получите консультацию инженера и предварительную оценку проекта за 2 дня. Мы рассчитаем стоимость индивидуально под ваши задачи. Закажите аудит — узнайте точную архитектуру и бюджет.