Что такое Galera Cluster
MariaDB Galera Cluster — синхронная мультимастер-репликация для MariaDB. Все три узла одновременно принимают запросы на запись. При падении одного узла кластер продолжает работу. Идеален для высокодоступных приложений.
Архитектура: 3 узла (минимум)
Три сервера (node1: 10.0.0.1, node2: 10.0.0.2, node3: 10.0.0.3) с MariaDB. Galera требует нечётное количество узлов для предотвращения split-brain.
Установка MariaDB на всех узлах
# На каждом сервере:
sudo apt update && sudo apt install mariadb-server
sudo systemctl stop mariadbКонфигурация Galera (на каждом узле)
sudo nano /etc/mysql/mariadb.conf.d/60-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
# Galera Cluster
wsrep_cluster_name="my_cluster"
wsrep_cluster_address="gcomm://10.0.0.1,10.0.0.2,10.0.0.3"
# Node identification (разное на каждом узле!)
wsrep_node_address="10.0.0.1" # NODE 1
wsrep_node_name="node1" # NODE 1
# SST Method
wsrep_sst_method=rsyncПервый запуск кластера (только на node1)
# ТОЛЬКО на первом узле:
sudo galera_new_cluster
# или
sudo mysqld --wsrep-new-cluster --user=mysql &Запуск остальных узлов
# На node2 и node3:
sudo systemctl start mariadbПроверка состояния кластера
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%';" | grep -E "wsrep_cluster_size|wsrep_cluster_status|wsrep_connected|wsrep_ready"
-- wsrep_cluster_size: 3 (все 3 узла в кластере)
-- wsrep_cluster_status: Primary
-- wsrep_connected: ON
-- wsrep_ready: ONТипичные ошибки Galera Cluster
| Сообщение | Что означает | Что делать |
|---|---|---|
| WSREP has not yet prepared node for application use | Узел ещё выполняет SST (State Snapshot Transfer) и не готов принимать запросы | Подождать завершения синхронизации, проверить wsrep_local_state_comment |
| wsrep_cluster_status: non-Primary | Узел потерял кворум и не видит большинство кластера | Проверить сеть между узлами, при необходимости выполнить bootstrap заново |
| Lock wait timeout exceeded; try restarting transaction | Galera использует оптимистичную блокировку и откатывает конфликтующие транзакции при сертификации | Приложение должно уметь повторять транзакцию при получении этой ошибки |
Split-brain и почему нужно нечётное число узлов
Galera определяет, какая часть кластера «главная» (Primary Component), по кворуму — простому большинству голосов узлов. Именно поэтому нужно нечётное число узлов:
- 3 узла: при разрыве сети на 1 и 2 узел большинство (2 из 3) продолжает работу, меньшинство переходит в режим non-Primary и отклоняет запросы.
- 4 узла: при разрыве строго пополам (2 на 2) кворума нет ни у одной из частей — кластер останавливается целиком, что хуже, чем при 3 узлах.
- 2 узла: любой разрыв связи между ними останавливает кластер — Galera на двух нодах защищает только от полного отказа одной из них, но не от сетевого разделения.
Когда Galera Cluster не подходит
Синхронная репликация означает, что коммит на одном узле ждёт подтверждения сертификации от остальных — это добавляет задержку на каждую транзакцию, особенно заметную между узлами в разных дата-центрах. Galera плохо подходит для приложений с частыми длинными транзакциями и большими BLOB/LOB-полями: SST и IST (Incremental State Transfer) передают данные целиком, и большая транзакция может надолго заблокировать сертификацию для всего кластера. Для типичного веб-приложения с короткими транзакциями и тремя узлами в одном дата-центре Galera работает предсказуемо; для распределённой по разным регионам записи лучше рассмотреть асинхронную репликацию.
Диагностика производительности кластера
-- Проверить статус flow control (означает, что узел не успевает применять транзакции)
SHOW STATUS LIKE 'wsrep_flow_control_paused';
SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';
-- Количество сертификационных конфликтов (deadlock на уровне кластера)
SHOW STATUS LIKE 'wsrep_local_cert_failures';
-- Состояние InnoDB на узле под нагрузкой
SHOW ENGINE INNODB STATUS\GЗначение wsrep_flow_control_paused ближе к 1 означает, что узел почти всё время стоит и ждёт, пока остальные догонят его по записи — обычно это сигнал слабого диска или сети на одном из узлов. Список готовых my.cnf под разный объём RAM — в статье про оптимизацию my.cnf, а про балансировку запросов между узлами — в статье про ProxySQL.
Частые вопросы
Можно ли добавить новый узел к уже работающему кластеру без остановки остальных?
Добавление нового узла к работающему кластеру не требует остановки остальных — на новом сервере устанавливают тот же пакет, указывают в конфигурации адрес существующих узлов через переменную подключения и запускают службу обычным способом, без ключа создания нового кластера. Узел автоматически получает полную копию данных через SST и присоединяется к кворуму, после чего становится равноправным участником записи.
Что делать, если один узел вышел из кластера и его нужно вернуть обратно?
Узел, который вышел из кластера, проще всего вернуть обычным перезапуском службы — при старте он свяжется с оставшимися узлами через адрес кластера и либо получит недостающие изменения через инкрементальную передачу состояния, либо, если отставание слишком большое, скачает данные целиком заново. Ключ создания нового кластера на нём использовать нельзя — это стирает его данные и создаёт отдельный кластер.
Обязательно ли ставить отдельный балансировщик перед кластером, или достаточно подключаться к одному узлу напрямую?
Подключаться напрямую к одному узлу технически можно, но тогда при его отказе приложение теряет соединение с базой, даже если остальные узлы кластера работают исправно. Балансировщик перед кластером распределяет запросы между доступными узлами и автоматически исключает из схемы тот, что перестал отвечать, поэтому для продакшена его стоит ставить, а не полагаться на один фиксированный адрес.
Чем Galera Cluster отличается от обычной репликации master-slave в MySQL?
Обычная репликация MySQL асинхронна и строится вокруг одного master: запись идёт только туда, а слейвы догоняют его с небольшой задержкой и предназначены в основном для чтения. Galera синхронна и мультимастерна — запись принимает любой узел, а коммит подтверждается только после сертификации на всех участниках кластера, что исключает отставание слейвов ценой дополнительной задержки на каждую транзакцию.