MariaDB Galera Cluster: когда нужен и как устроен

В мире реляционных СУБД устойчивость к отказам и предсказуемое время восстановления чаще всего достигаются через репликацию и автоматическое переключение. Для MariaDB один из зрелых путей к высокой доступности — Galera Cluster, или просто Galera: синхронная (точнее, «виртуально синхронная») репликация с multi-master семантикой. В этом обзоре разберёмся, когда Galera имеет смысл, как она устроена, какие ограничения и подводные камни у неё есть, и на что смотреть при проектировании и эксплуатации.

Кому и когда нужен Galera Cluster

Сценарии, где Galera Cluster для MariaDB уместен:

• Критичные OLTP-системы с высоким SLA, где RPO≈0 и RTO минимальны: потеря транзакций неприемлема, а простаивать нельзя.
• Много чтений и средняя нагрузка по записям, при этом важнее консистентность и упрощённое автоматическое переключение узлов.
• Инфраструктуры, где не хочется возиться с внешним failover-менеджментом на асинхронной репликации и ловить рассинхрон.
• Кластеры в пределах одной площадки или одного региона с небольшой сетевой задержкой между узлами.

А когда Galera не лучший выбор:

• Высокая задержка между датацентрами (межрегиональная/межконтинентальная топология). Коммиты «растягиваются» по RTT, и латентность убьёт пропускную способность.
• Очень write-интенсивные нагрузки, особенно с конфликтами по одним и тем же ключам или с крупными транзакциями (массовые UPDATE/DELETE на большие диапазоны).
• Нетривиальные DDL-потоки, когда схема часто меняется. В Galera есть режимы применения DDL, и они накладывают ограничения на время и окна обслуживания.
• Неоднородный железный стек: один «медленный» узел будет тормозить весь кластер из‑за flow control.

Коротко: Galera — это про HA и консистентность с минимальным RPO, если RTT между узлами невелик и объём конфликтных записей умеренный.

Как устроен Galera Cluster внутри

Galera — это wsrep-провайдер для MariaDB, обеспечивающий общий порядок транзакций и репликацию «на коммите». Вместо привычных бинарных логов с последующей асинхронной репликацией здесь применяется механизм сертификации.

Виртуально синхронная репликация и сертификация

Жизненный цикл транзакции упрощённо выглядит так:

1. Транзакция выполняется локально на узле, но окончательное подтверждение откладывается до коммита.
2. На этапе COMMIT формируется «write-set» (набор изменений) и рассылается всем узлам первичного компонента.
3. Каждый узел проводит сертификацию: проверяет, не конфликтует ли write-set с уже закоммиченными транзакциями.
4. Если конфликтов нет — транзакция принимается к применению в общем порядке; если есть — клиент получает ошибку сертификации, и приложение должно повторить операцию.

Важно: приложение видит успешный COMMIT только после того, как транзакция сертифицирована во всём «первичном компоненте» (primary component). Это и даёт RPO≈0: другие узлы уже приняли транзакцию к применению и не «отстанут» асинхронно.

Кворум и первичный компонент

Galera использует модель кворума: узлы объединяются в компонент, и только «первичный» компонент может выполнять записи. При сетевом разделении («split brain») меньшая по кворуму группа станет непервичной и перейдёт в read-only до восстановления связи. Отсюда практическое правило — держим нечётное число голосующих участников (обычно 3, 5), при необходимости добавляем garbd (арбитр без данных) для поддержания кворума.

IST и SST: как узлы догоняют кластер

Когда узел отстаёт и возвращается, возможны два пути синхронизации:

• IST (Incremental State Transfer) — быстрый догон только недостающих write-set из gcache. Требует, чтобы донор ещё держал историю изменений.
• SST (State Snapshot Transfer) — полная передача снимка базы. Дорогая по диску и сети операция; лучше планировать и выбирать метод, например mariabackup.

Размер gcache стоит рассчитывать так, чтобы покрыть объём записей за типичный простой узла, иначе будет частый SST.

Требования и ограничения MariaDB Galera

• Движок — InnoDB (или XtraDB). Таблицы должны иметь первичные ключи. MyISAM и другие небезопасны.
• Изоляция транзакций — не выше REPEATABLE READ; SERIALIZABLE поддерживается ограниченно и может вести к неожиданным блокировкам.
• Автоинкремент: в multi-master возможны коллизии. Есть автонастройка wsrep_auto_increment_control, однако надёжнее использовать UUID, ULID или распределители ключей.
• DDL: режимы применения — TOI (Total Order Isolation) и RSU (Rolling Schema Upgrade). TOI даёт глобальный порядок, но может «подвесить» коротко весь кластер на время DDL. RSU применяет локально, но рискует временной неконсистентностью. В проде обычно планируют TOI-окна.
• Сетевые требования: низкая задержка и стабильный канал между узлами. 1 Гбит/с — нижняя практическая планка; при SST желателен быстрый диск и широкая труба.

Производительность и характер нагрузки

Важный момент: пропускная способность коммитов в Galera ограничена латентностью сети и скоростью самого медленного узла. Чем выше межузловой RTT, тем медленнее коммиты. Отсюда рекомендации:

• Держать узлы как можно ближе физически (одна площадка/один регион).
• Избегать больших транзакций. Дробить пачки обновлений на небольшие порции.
• Минимизировать конфликты обновлений одних и тех же строк — это приводит к отказам сертификации и ретраям.
• По возможности направлять «горячие» записи на один узел через прокси (ProxySQL/HAProxy) и распределять чтения по всем узлам.
• Следить за flow control: если очередь применения растёт на каком-то узле, он начнёт тормозить остальных. Наблюдайте метрики применяющего потока и очередей.

Ключевые параметры конфигурации

Ниже — минимальный ориентир. Конкретные значения подбираются под нагрузку и сеть.

# /etc/my.cnf.d/galera.cnf
[mysqld]
# Базовые wsrep-настройки
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name=prod-galera
wsrep_cluster_address=gcomm://10.0.0.11,10.0.0.12,10.0.0.13
wsrep_node_name=db1
wsrep_node_address=10.0.0.11

# Метод SST/IST
wsrep_sst_method=mariabackup
wsrep_sst_auth=sstuser:sstpass

# Параллельное применение
wsrep_slave_threads=8

# Управление автоинкрементом
wsrep_auto_increment_control=ON

# GCache для IST (размер под объём записей за N часов простоя)
wsrep_provider_options="gcache.size=4G"

# Безопасность
binlog_format=row
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Первый узел кластера создаётся особым образом (bootstrap), последующие подключаются к нему. Командочки зависят от дистрибутива, но логика одна: для bootstrap указываем, что данный узел запускает новый первичный компонент, а не пытается присоединиться к существующему.

Шифрование репликации

Galera поддерживает TLS между узлами. Для этого настраивают параметры провайдера, указывая ключ, сертификат и CA. Это особенно важно между площадками и в облачной инфраструктуре. Для публичных клиентских подключений на фронтендах используйте SSL-сертификаты.

# Пример (конкретные пути и имена опций зависят от версии galera)
wsrep_provider_options="socket.ssl_key=/etc/mysql/ssl/server-key.pem;socket.ssl_cert=/etc/mysql/ssl/server-cert.pem;socket.ssl_ca=/etc/mysql/ssl/ca.pem"

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Эксплуатация: запуск, расширение, апгрейды

Инициализация и добавление узлов

Старт нового кластера выполняется с bootstrap на первом узле. Второй и третий узлы подключаются обычным запуском демона, который, увидев wsrep_cluster_address, найдёт пиров и присоединится.

Чтобы уменьшить влияние SST на прод-ноду, выбирают явного донора, а для JOINER на время синхронизации можно включать wsrep_desync=ON, чтобы он не участвовал в flow control, пока догоняет.

Апгрейды без простоя

Minor-обновления MariaDB и Galera обычно можно раскатывать по одному узлу: выводим узел из балансировки, ставим обновления, возвращаем обратно. Следите за совместимостью версий провайдера (например, galera-4) и протокола. На время тяжёлых операций включайте wsrep_desync, чтобы узел не тормозил кластер.

Резервное копирование

Бекапы делают с помощью mariabackup (совместим с SST-методом). Допустимо снимать бэкап с любого узла, но лучше выделять отдельного «донора», чтобы не бить по латентности боевых узлов. Помните про IOPS и полосу для полного снапшота. Для восстановления «до секунды» пригодится PITR по binlog/GTID.

Мониторинг и метрики

Основные переменные статуса wsrep, за которыми стоит следить:

• wsrep_cluster_status — PRIMARY или нет. Если не PRIMARY, узел не сможет коммитить записи.
• wsrep_ready и wsrep_connected — готовность к работе и связь с кластером.
• wsrep_local_state_comment — состояние: JOINER, JOINED, SYNCED и т.д.
• wsrep_flow_control_paused — доля времени в flow control. Растёт — значит где-то «забились» очереди.
• wsrep_local_send_queue_avg и wsrep_local_recv_queue_avg — очереди отправки/приёма; индикаторы сетевых или дисковых узких мест.
• wsrep_apply_ool и wsrep_cert_deps_distance — эффективность параллельного применения.

Типичные проблемы и как их избегать

Конфликты при сертификации

При параллельных апдейтах одних и тех же строк транзакции будут откатываться на этапе COMMIT. Симптом — увеличивающееся число ошибок сертификации у клиентов. Решения:

• Декомпозировать «горячие» структуры данных, уменьшить зону конфликтов.
• Роутить записи конкретных сущностей на один узел.
• Сократить длительность транзакций и размер батчей.

Flow control тормозит весь кластер

Если один узел не успевает применять write-set, он включает flow control, и остальные вынуждены «подстраиваться». Диагностируйте дисковую подсистему, CPU, настройки wsrep_slave_threads, а также медленные запросы, мешающие применению.

Частые SST вместо IST

Признак слишком маленького gcache или чрезмерной нагрузки. Увеличьте gcache.size до объёма изменений за окно типичного простоя узла. Старайтесь сокращать время вне кластера, чтобы попадать в IST.

DDL блокирует всех

В режиме TOI DDL выполняется в общем порядке, что на время операции блокирует применяющие потоки. Планируйте окна изменений схемы, заранее оценивайте длительность, предварительно оптимизируйте таблицы. RSU используйте осознанно и только когда понимаете риски временной неконсистентности.

Проектирование: схема, ключи, транзакции

• Всегда первичные ключи. Без PK Galera не сможет корректно формировать детерминированные write-set.
• Избегайте больших каскадных операций по множеству строк. Лучше батчи небольшими порциями.
• Пересмотрите автоинкремент на горячих таблицах: UUID/ULID, либо аккуратная настройка автоинкремента в multi-master.
• Держите транзакции короткими. Чем меньше «окно» между началом и коммитом, тем ниже вероятность конфликтов.

Сетевой и аппаратный дизайн

• Три узла — минимально жизнеспособная конфигурация для кворума. Нечётное количество — проще жить.
• Одинаковое железо и конфигурация ОС. Кластер «едет» со скоростью самого медленного узла.
• Стабильный низкий RTT между узлами. Если нужна геораспределённость — лучше несколько локальных кластеров с асинхронной связью между ними, чем один «растянутый» Galera.
• Планируйте диск и сеть под SST: быстрый SSD/NVMe, достаточная полоса, отсутствие узких мест на уровне файловой системы и ограничений ОС.
• Время — в ногу: синхронизация часов через NTP/chrony обязательна.

Для предсказуемости и изоляции ресурсов удобнее собирать кластер на одинаковых инстансах. В облачной инфраструктуре на VDS проще стандартизировать CPU, RAM и диски и быстро заменять узлы в случае деградации.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Балансировка трафика и паттерны доступа

Galera допускает запись на любой узел, но практика показывает: эффективнее и предсказуемее направлять большую часть записей на один узел (per-tenant, per-shard, per-service), а чтения распределять по остальным. Для этого используют балансировщики с проверкой роли/состояния: направляем чтения только на wsrep_ready=ON и SYNCED-узлы, а запись — на выбранный «первичный» для данного сегмента данных. Так уменьшается риск конфликтов, и проще прогнозировать задержки.

Сравнение с альтернативами

Асинхронная репликация в MariaDB проще и быстрее на запись, но требует внешней логики failover, и RPO может быть больше нуля. Полусинхрон — компромисс, однако сложнее обеспечить единый порядок транзакций. MySQL Group Replication предлагает схожую по идее модель с собственными нюансами. Если нужен именно «единый порядок», кворум и RPO≈0 в рамках площадки — Galera остаётся надёжным вариантом. Для асинхронного сценария посмотрите наш гайд по фейловеру на GTID и полусинхроне.

Чек-лист перед продом

• План развертывания: bootstrap, порядок подключения узлов, подготовленные аккаунты для SST.
• Тестовые репетиции SST/IST и оценка времени. gcache рассчитан по реальным метрикам записи.
• Роутинг запросов и стратегия распределения: где пишем, где читаем.
• Мониторинг wsrep-метрик и алерты на потерю PRIMARY, flow control, рост очередей.
• Описанные процедуры восстановления, апгрейда и замены узла, включая безопасное выключение.
• План DDL-изменений и окна TOI. При необходимости — пилотные замеры на копии.
• Шифрование трафика между узлами и базовые настройки безопасности MariaDB.

Итоги

Galera Cluster для MariaDB — зрелая технология синхронной репликации с кворумом и общим порядком транзакций. Она даёт высокую доступность и RPO≈0, но требует дисциплины: низкая сетевуха между узлами, аккуратная схема и транзакции, продуманный роутинг, контроль за flow control и размером gcache. Если ваша система критична к потерям данных и простоям, а задержки сети между узлами малы, Galera — отличный кандидат на роль базового HA-кластера.

Если же нагрузка по записи велика, операции конфликтуют, а узлы далеко друг от друга, стоит рассмотреть альтернативные архитектуры: шардирование с локальными кластерами, асинхронную репликацию с грамотным failover, или другие механизмы консенсуса — в зависимости от требований к консистентности, задержкам и сложности эксплуатации.