Що таке 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: запис іде лише туди, а slave-вузли наздоганяють його з невеликою затримкою і призначені здебільшого для читання. Galera синхронна і мультимастерна — запис приймає будь-який вузол, а коміт підтверджується лише після сертифікації на всіх учасниках кластера, що виключає відставання slave-вузлів ціною додаткової затримки на кожну транзакцію.