Представьте: ваш интернет-магазин работает в Европе и Азии. Запись в базу данных из Азии идёт через Европу с задержкой более 100 мс — это критично для работы каталога и корзины. Мы столкнулись с такой задачей в проекте с онлайн-ритейлером на 500 тыс. товаров и решили её внедрением Master-Master репликации. Теперь запись идёт локально в каждом регионе, а данные синхронизируются между узлами без потерь. Более 5 лет настраиваем репликации и выполнили 30+ проектов высокой сложности.
Почему 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. Конфигурация проста:
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 сетей используйте выделенные каналы.
Комплексная настройка под ключ
Мы предлагаем полный цикл: анализ нагрузки, выбор решения, развёртывание узлов, конфигурация репликации и балансировки, нагрузочное тестирование, мониторинг, документирование и обучение команды. Гарантийная поддержка — 1 месяц.
Сроки: 3–4 рабочих дня на трёхузловой кластер. Стоимость рассчитывается индивидуально и зависит от сложности и количества узлов.
Закажите аудит текущей репликации — мы выявим узкие места и предложим оптимизацию. Свяжитесь с нами для консультации по вашей архитектуре.
Дополнительную информацию можно найти в статье Galera Cluster.