MariaDB Galera Cluster: высокая доступность и синхронная репликация для бизнес-приложений

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет я ставил десятки MySQL/MariaDB-инсталляций — от одиночных серверов на офисных NAS до трёхузловых Galera-кластеров на Dell Xeon Platinum 8280 с 40G Mellanox в дата-центре МТС. И знаю по опыту: одиночный MariaDB падает раз в полтора-два года (диск, память, обновление ядра), и каждый такой инцидент — это простой на 1–6 часов. Galera снимает эту боль.

Зачем нужен Galera Cluster

Galera Cluster — это расширение MariaDB/MySQL, реализующее синхронную мульти-мастер репликацию. В отличие от классической master-slave, где slave может отстать на минуты, в Galera транзакция считается зафиксированной только после подтверждения всеми узлами. Это даёт три ключевых преимущества:

• Zero data loss. Любой узел может умереть в середине транзакции — данные уже на остальных.
• Прозрачный failover. Приложение переключается на другой узел за секунду, без разбора бинлогов и promote.
• Горизонтальное масштабирование чтения. Все узлы отдают свежие данные.

Цена — лишний сетевой оверхед при коммите, ~0,5–2 мс на транзакцию в локальной сети. Для OLTP-приложений с небольшими транзакциями — терпимо.

Требования к инфраструктуре

Если узлы разнесены на разные площадки с задержкой >10 мс — забудьте про Galera, используйте асинхронную репликацию или MariaDB Replication Manager.

Установка MariaDB на три узла

# На всех трёх узлах (Ubuntu 22.04)
apt update
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | \
  sudo bash -s -- --mariadb-server-version="mariadb-10.11"
apt install mariadb-server mariadb-client galera-4

systemctl stop mariadb

Конфигурация кластера

Основной конфиг /etc/mysql/mariadb.conf.d/60-galera.cnf — одинаковый на всех узлах, кроме параметра wsrep_node_name и wsrep_node_address:

[galera]
wsrep_on                = ON
wsrep_provider          = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name      = "office_cluster"
wsrep_cluster_address   = "gcomm://10.0.10.11,10.0.10.12,10.0.10.13"

# Индивидуально на каждом узле
wsrep_node_name         = "db01"
wsrep_node_address      = "10.0.10.11"

wsrep_sst_method        = mariabackup
wsrep_sst_auth          = "sstuser:StrongPassword2026"
wsrep_slave_threads     = 4
wsrep_provider_options  = "gcache.size=2G; gcs.fc_limit=256"

binlog_format           = ROW
default_storage_engine  = InnoDB
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 16G

bind-address            = 0.0.0.0

Первичный запуск кластера

# На первом узле инициализируем новый кластер
galera_new_cluster

# Проверяем
mysql -uroot -p -e "SHOW STATUS LIKE 'wsrep_%';"

# Создаём SST-пользователя
mysql -uroot -p -e "
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'StrongPassword2026';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;
"

# На втором и третьем узле — обычный старт
systemctl start mariadb

# Проверяем размер кластера
mysql -uroot -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
# wsrep_cluster_size = 3 — всё хорошо

SST vs IST: передача состояния на новый узел

Когда новый узел присоединяется к кластеру, он должен получить текущее состояние базы. Есть два варианта: SST (полная копия) и IST (только дельта). Galera сама выбирает подходящий в зависимости от размера gcache и отставания узла.

Я всегда использую mariabackup как метод SST — он выполняет горячее копирование без блокировок таблиц. Альтернативы rsync и mysqldump — медленные или блокирующие.

# Увеличить gcache, чтобы IST работал чаще
# В 60-galera.cnf
wsrep_provider_options = "gcache.size=8G; gcache.page_size=128M; gcs.fc_limit=256"

Split-brain и восстановление после падения

Если из трёх узлов два падают одновременно, оставшийся теряет кворум и переходит в режим non-primary — база отвечает ошибкой на любой запрос. Это защита от split-brain. Чтобы снова запустить работу:

# Если мы уверены, что этот узел имеет самые свежие данные
mysql -uroot -p -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';"

# Или полный рестарт как нового кластера
# 1) Посмотреть /var/lib/mysql/grastate.dat на каждом узле
cat /var/lib/mysql/grastate.dat
# safe_to_bootstrap: 1 — можно запускать galera_new_cluster

# 2) Запускаем на узле с наиболее высоким seqno
galera_new_cluster

Я всегда веду чек-лист восстановления с конкретными командами — в момент аварии руки не должны трястись.

MaxScale перед кластером

Напрямую подключать приложение ко всем трём узлам — плохая идея: split-brain, конфликты, деадлоки. Правильно — поставить перед кластером прокси, который распределяет запросы. У нас на практике это MariaDB MaxScale с режимом readwritesplit.

# Установка на отдельной виртуалке
apt install maxscale

# /etc/maxscale.cnf (фрагмент)
[server1]
type=server
address=10.0.10.11
port=3306

[Galera-Service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxuser
password=MaxUserPass2026

[Galera-Listener]
type=listener
service=Galera-Service
protocol=MariaDBClient
port=3307

Приложение подключается к MaxScale на порт 3307, MaxScale сам маршрутизирует SELECT на реплики, а запись — на primary-узел.

Кейс: HA-кластер для корпоративного портала на 240 пользователей

В марте 2026 мы внедрили Galera-кластер для клиента — логистическая компания в Москве с веб-порталом заказов на PHP/Laravel, MariaDB 500 ГБ. До этого у них стоял одиночный сервер на железе 2018 года, упавший в декабре на 7 часов в пиковый сезон. Убытки от простоя — порядка 3 млн руб.

Развернули три виртуалки в дата-центре МТС (каждая 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe) на хостах Dell Xeon Platinum 8280, связанные 40G Mellanox. MaxScale — на отдельной виртуалке с keepalived и VIP для failover. Миграция данных заняла 4 часа, переключение порталов — 20 минут в выходные.

Итог за 3 месяца эксплуатации: два плановых апдейта с rolling restart без простоя, один инцидент (падение узла из-за сбоя ZFS), который приложение даже не заметило. Стоимость внедрения — 185 000 руб, ежемесячная поддержка — 35 000 руб.

Мониторинг Galera

• wsrep_cluster_size — число узлов в кластере (должно быть 3).
• wsrep_cluster_status — Primary при нормальной работе.
• wsrep_local_state_comment — Synced когда узел в строю.
• wsrep_flow_control_paused — процент времени flow control. Больше 10% = проблемы с отставанием узла.
• wsrep_cert_deps_distance — параллелизм репликации, растёт при нагрузке.

# В Zabbix/Prometheus через mariadb_exporter
# Алерты:
# wsrep_cluster_size != 3 — critical
# wsrep_cluster_status != "Primary" — critical
# wsrep_flow_control_paused > 0.1 — warning

FAQ — MariaDB Galera Cluster

Почему для Galera нужно минимум 3 узла?

Galera требует кворум. При двух узлах разрыв сети приведёт к split-brain. Три узла гарантируют работу при падении любого одного.

Что такое SST и IST?

SST — полная передача базы новому узлу. IST — только недостающие транзакции из gcache.

Можно ли писать на все узлы?

Технически да, но это ведёт к deadlock-ам. Настраивайте MaxScale с одним активным писателем.

Как восстановить кластер после полной остановки?

Найти узел с наиболее свежими данными (по grastate.dat) и запустить galera_new_cluster. Остальные присоединятся обычным стартом.

Подходит ли Galera для 1С?

Нет, 1С не работает с MariaDB. Для корпоративных порталов и CRM — отличный выбор.