Реплікація 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% бюджету.

Ознаки, коли кластеризація необхідна

Не кожному проекту. Конкретні маркери:

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

Іноді вистачає композитного кешу, оптимізації SQL та вертикального масштабування. Ми чесно скажемо, якщо кластер поки не потрібен. Інвестиції в кластеризацію окупаються за 3-6 місяців при пікових навантаженнях.

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

Балансувальник. 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 дні. Ми розрахуємо вартість індивідуально під ваші завдання. Замовте аудит — дізнайтеся точну архітектуру та бюджет.