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