Master-slave реплікація: усунення вузького горла СУБД

Master-slave реплікація: як усунути вузьке горло СУБД

Ваш веб-застосунок гальмує на сторінках зі звітами? База даних не справляється з напливом користувачів, а єдиний сервер — точка відмови. Ми стикалися з цим десятки разів: SELECT-запити блокують INSERT, аналітичні звіти «роняють» production, а бекапи на живій базі призводять до простою. Кожна така проблема коштує часу та грошей. Рішення — налаштування master-slave реплікації під ключ. Ми гарантуємо відмовостійкість та розвантаження основного сервера, перевірені на 100+ проектах.

Реплікація Master-Slave (Primary-Replica в новій термінології) — асинхронна або синхронна доставка даних з основного сервера на одну або декілька реплік. Вона дозволяє масштабувати читання: до 80% запитів можна направляти на репліки, залишаючи мастер тільки для запису. Це знижує latency та виключає конкуренцію за ресурси. З нашим досвідом налаштування більше 50 проектів ми реалізуємо таку архітектуру за 1–3 дні.

Чому Master-Slave реплікація критична для вашого застосунку?

Без реплікації ви ризикуєте:

• Відмовою — при збої майстра дані недоступні до відновлення. Середній час простою вручну — 2–4 години.
• Деградацією — аналітичні запити блокують запис, збільшуючи TTFB у 3–5 разів.
• Дорогими бекапами — зняття дампа на майстрі блокує таблиці, викликаючи простої.

Порівняно з єдиною базою, архітектура з однією реплікою обробляє до 5 разів більше читаючих запитів, а з ProxySQL — до 10 разів. Наприклад, проект інтернет-магазину після налаштування реплікації знизив час відповіді на запити звітів з 12 до 0.8 секунди — в 15 разів швидше.

Коли потрібна синхронна реплікація?

Синхронна реплікація гарантує нульову втрату даних при збої майстра. Вона незамінна для фінансових транзакцій або критичних до цілісності даних. Однак ціна — збільшення latency запису на 30–50% та зниження пропускної здатності. Ми рекомендуємо синхронний режим для ядра застосунку, асинхронний — для аналітики.

Як ми налаштовуємо реплікацію в PostgreSQL та MySQL?

Ми використовуємо лише перевірені підходи: streaming replication для PostgreSQL та GTID-реплікацію для MySQL. У таблиці — ключові відмінності:

Типові помилки при налаштуванні: некоректний wal_level (має бути replica або logical), нестача max_wal_senders для декількох реплік, ігнорування replication lag (відсутність моніторингу). Запис на репліку в read-only режимі призводить до розсинхронізації — це одна з частих причин відмови.

Приклад конфігурації PostgreSQL майстра:

# postgresql.conf wal_level = replica max_wal_senders = 10 wal_keep_size = 1GB synchronous_commit = on synchronous_standby_names = 'replica1' 

Ініціалізація репліки:

pg_basebackup -h master -U replication -D /var/lib/postgresql/14/main -P -Xs -R 

Приклад конфігурації MySQL майстра:

[mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW gtid_mode = ON enforce_gtid_consistency = ON 

Запуск репліки MySQL з GTID:

CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='replication', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1; START SLAVE; 

Маршрутизація через ProxySQL:

INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, 'master', 3306); INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, 'replica', 3306); INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup) VALUES (1, 1, '^SELECT', 20), (2, 1, '.*', 10); LOAD MYSQL SERVERS TO RUNTIME; LOAD MYSQL QUERY RULES TO RUNTIME; 

Які етапи включає налаштування реплікації?

Процес включає наступні кроки:

1. Аудит поточного навантаження та архітектури: вимірюємо пікові RPS, latency, розмір бази.
2. Вибір топології: одна репліка або декілька, асинхронна чи синхронна.
3. Конфігурація майстра: wal_level, max_wal_senders, gtid_mode.
4. Ініціалізація реплік через pg_basebackup або mysqldump.
5. Налаштування маршрутизації (ProxySQL / pgBouncer) та розділення запитів на читання/запис.
6. Моніторинг лагу: Prometheus + Grafana з алертами при лазі >60 секунд.
7. Документація та навчання команди, передача скриптів failover.

Порівняння асинхронної та синхронної реплікації

Що входить до роботи

• Повна документація щодо конфігурації та процедури failover.
• Дампи та скрипти для швидкого відновлення.
• Доступи до моніторингу (Grafana, алерти в Telegram).
• Навчання команди: як перевіряти статус реплікації та виконувати перемикання.

Скільки це коштує та коли окупається?

Терміни залежать від складності:

• Одна репліка + базовий моніторинг — 1 день.
• Реплікація з ProxySQL та failover — 2–3 дні.

Вартість розраховується індивідуально. Але інвестиції окупаються швидко: економія на інфраструктурі за рахунок реплік для читання може досягати 40%, а час відновлення при збої скорочується з годин до хвилин. Типовий проект окупається за 2–3 місяці. Якщо у вас вже є проект — зв'яжіться з нами для безкоштовної оцінки. Замовте налаштування реплікації та отримайте відмовостійку архітектуру.

PostgreSQL Documentation on Streaming Replication — подробиці протоколу реплікації. MySQL GTID Replication — офіційний мануал з налаштування.