Уявіть: ваш інтернет-магазин працює в Європі та Азії. Запис до бази даних з Азії йде через Європу із затримкою понад 100 мс — це критично для роботи каталогу та кошика. Ми зіткнулися з таким завданням у проекті з онлайн-рітейлером на 500 тис. товарів і вирішили його впровадженням Master-Master реплікації. Технологія multi-master реплікації дозволяє писати локально в кожному регіоні, а дані синхронізуються між вузлами без втрат. Ми виконали 30+ проектів з високою складністю, маючи понад 5 років досвіду.
Чому Master-Master, а не Master-Slave?
Master-Slave — це класика: один вузол пише, інші читають. Але коли застосунок працює в розподіленому середовищі, latency запису стає вузьким місцем. Master-Master знімає це обмеження: кожен вузол може приймати запис. Згідно з документацією Galera, синхронна реплікація multi-master забезпечує строгу консистентність і нульовий час перемикання при збої. Galera Cluster забезпечує перемикання за <1 сек — це в 10 разів швидше, ніж ручний failover на Master-Slave.
Коли потрібна Master-Master реплікація?
- Застосунки в різних регіонах повинні писати локально з синхронізацією.
- Потрібна відмовостійкість без єдиної точки відмови.
- Затримка запису через єдиний майстер перевищує допустимі 50 мс.
- Окупність такого рішення — 2–3 місяці при навантаженні від 10 тис. запитів на секунду.
Як налаштувати Galera Cluster на трьох вузлах
- Встановіть Galera на всі вузли (наприклад, Ubuntu 22.04).
- Налаштуйте
/etc/mysql/conf.d/galera.cnfяк показано нижче. - Ініціалізуйте перший вузол командою
galera_new_cluster. - Запустіть MySQL на інших вузлах — вони приєднаються автоматично.
- Перевірте стан:
SHOW STATUS LIKE 'wsrep_cluster_size';— має бути 3.
# /etc/mysql/conf.d/galera.cnf [mysqld] binlog_format = ROW default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 bind-address = 0.0.0.0 # Galera Provider wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_cluster_name = "production_cluster" wsrep_cluster_address = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12" wsrep_sst_method = rsync # Унікально для кожного вузла wsrep_node_address = "192.168.1.10" wsrep_node_name = "node1" Деталі конфігурації SST
Для SST можна використовувати rsync або xtrabackup. У production рекомендуємо xtrabackup — він не блокує таблиці під час повної синхронізації.Як уникнути втрати даних при реплікації?
Втрата даних у multi-master можлива при збої вузла до синхронізації. Для мінімізації ризиків використовуйте синхронну реплікацію (Galera) з автоматичним відновленням після збою. У BDR налаштуйте слоти реплікації із затримкою не більше 1 секунди. Регулярне створення бекапів за допомогою xtrabackup або pg_dump знижує втрати до 1 хвилини при повній відмові кластера.
Налаштування PostgreSQL BDR
BDR (Bi-Directional Replication) — розширення для асинхронної multi-master реплікації в PostgreSQL. Воно підходить для завдань, де допустима eventual consistency (затримка синхронізації до 1–2 с).
-- Підключення розширення CREATE EXTENSION bdr; -- Ініціалізація першого вузла SELECT bdr.bdr_group_create( local_node_name := 'node1', node_external_dsn := 'host=192.168.1.10 port=5432 dbname=myapp' ); -- Приєднання другого вузла SELECT bdr.bdr_group_join( local_node_name := 'node2', node_external_dsn := 'host=192.168.1.11 port=5432 dbname=myapp', join_using_dsn := 'host=192.168.1.10 port=5432 dbname=myapp' ); Порівняння Galera та BDR
| Параметр | Galera Cluster | PostgreSQL BDR |
|---|---|---|
| Тип реплікації | Синхронна | Асинхронна |
| Консистентність | Строга | Підсумкова |
| Latency запису | Висока (залежить від мережі) | Низька |
| Підтримка DDL | Блокує кластер | Не блокує |
| Ліцензія | GPL | PostgreSQL license |
Вирішення конфліктів запису
Конфлікти виникають, коли два вузли одночасно змінюють один запис. У проекті з рітейлером ми застосували розбиття за регіонами — кожна таблиця відповідає за свій географічний сегмент. Це виключило перетинання та знизило конфлікти на 95%.
| Стратегія | Принцип | Застосування |
|---|---|---|
| Last Write Wins | Перемагає останній timestamp | Некритичні дані, IoT |
| Origin wins | Перемагає вузол-джерело | Регіональні дані |
| Custom resolver | Бізнес-логіка злиття | Складні агрегати |
| Application-level | Детерміновані ключі | Потребує архітектурного опрацювання |
Балансування та моніторинг
Для рівномірного розподілу запитів використовуємо ProxySQL балансування. ProxySQL здатний обробляти до 100 тис. запитів/с. Конфігурація проста:
INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight) VALUES (10, '192.168.1.10', 3306, 1), (10, '192.168.1.11', 3306, 1), (10, '192.168.1.12', 3306, 1); Моніторинг ведемо через Prometheus + Grafana. Ключові метрики: wsrep_local_recv_queue_avg (черга застосування транзакцій має бути <1) та wsrep_local_cert_failures (конфлікти сертифікації близькі до нуля).
Обмеження та підводні камені
- Galera не підтримує MyISAM та MEMORY таблиці.
- AUTO_INCREMENT потребує
innodb_autoinc_lock_mode=2. - DDL блокує кластер — застосовуйте
pt-online-schema-change. - Затримка між вузлами >5 мс знижує продуктивність запису на 30–40%. Для low-latency мереж використовуйте виділені канали.
Комплексне налаштування під ключ
Пропонуємо налаштування під ключ за 3–4 робочі дні. Напишіть нам для консультації — оцінимо ваш проект безкоштовно.
Що входить у роботу:
- Аналіз навантаження та вибір рішення.
- Розгортання 3 вузлів Galera Cluster.
- Налаштування ProxySQL балансування.
- Моніторинг Prometheus+Grafana.
- Навантажувальне тестування.
- Документація та навчання команди.
- Гарантійна підтримка 1 місяць.
Вартість налаштування тривузлового Galera Cluster — від $1500. Економія на інфраструктурі до 40% за рахунок використання власних серверів.
Додаткову інформацію можна знайти в статті Galera Cluster.