Menu
Szybki wybór
Hosting Domeny VPS SSL Kalkulator Porównania FAQ
Aktywne kody
Wszystkie kody rabatowe

MySQL Galera Cluster — multi-master replikacja MariaDB

Opublikowano: 10 kwietnia 2026 · Kategoria: VPS i serwery

Klasyczna replikacja MySQL master-slave sprawdza się przy odczytach, ale ma krytyczną wadę: tylko jeden serwer przyjmuje zapisy. Awaria mastera wymaga ręcznej promocji slave i jest widoczna dla użytkowników. Galera Cluster rozwiązuje ten problem przez synchroniczną replikację multi-master: każdy z trzech (lub więcej) węzłów może przyjmować zapisy i odczyty jednocześnie, a awaria jednego węzła jest transparentna dla aplikacji. MariaDB Galera jest dojrzałym rozwiązaniem używanym przez platformy e-commerce, WordPress multisite i aplikacje wymagające zero-downtime deploymentów. Ten artykuł pokazuje konfigurację trzywęzłowego klastra od zera.

Wymagania i architektura klastra

Minimalna konfiguracja Galera Cluster to 3 węzły (dla kworum). Każdy węzeł powinien być na oddzielnym serwerze fizycznym lub VPS w innej strefie dostępności. Sieć między węzłami musi mieć niskie opóźnienia (idealnie < 1ms) — Galera to synchroniczna replikacja, więc opóźnienia sieci bezpośrednio wpływają na latencję zapisów. Wymagane porty: 3306 (MySQL), 4444 (SST), 4567 (Galera replikacja), 4568 (IST).

# Instalacja MariaDB z Galera na WSZYSTKICH 3 wezlach
# Ubuntu 22.04 / Debian 12

sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4

# lub przez oficjalne repo MariaDB (dla najnowszej wersji)
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
sudo apt install -y mariadb-server mariadb-galera-server

# Sprawdz wersje
mysql --version
mysql -e "SHOW GLOBAL VARIABLES LIKE 'wsrep_provider%';"

# Otworz porty w firewall na WSZYSTKICH wezlach (uzywamy iptables)
sudo iptables -A INPUT -p tcp --dport 3306 -s INNE_IP_WEZLA -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 4444 -s INNE_IP_WEZLA -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 4567 -s INNE_IP_WEZLA -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 4568 -s INNE_IP_WEZLA -j ACCEPT
sudo iptables -A INPUT -udp --dport 4567 -s INNE_IP_WEZLA -j ACCEPT

Konfiguracja węzłów — /etc/mysql/mariadb.conf.d/60-galera.cnf

# /etc/mysql/mariadb.conf.d/60-galera.cnf
# Konfiguracja identyczna na wszystkich wezlach, zmienia sie tylko:
# wsrep_node_address i wsrep_node_name

[mysqld]

# --- Wsrep (Galera) ---
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Lista wszystkich wezlow klastra
wsrep_cluster_address="gcomm://192.168.1.10,192.168.1.11,192.168.1.12"

# Nazwa klastra (musi byc identyczna na wszystkich wezlach)
wsrep_cluster_name="galera_prod"

# Adres tego wezla (rozny na kazdym wezle)
wsrep_node_address="192.168.1.10"   # <- zmien per wezel
wsrep_node_name="galera-node1"      # <- zmien per wezel

# Metoda SST — mariabackup (nie blokuje donora, wymaga mariadb-backup)
wsrep_sst_method=mariabackup
wsrep_sst_auth="galera_sst:strong_password_here"

# Retry polaczen przy starcie
wsrep_provider_options="pc.recovery=TRUE; gcache.size=1G"

# Binlog format musi byc ROW dla Galery
binlog_format=ROW

# InnoDB ustawienia dla Galery
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0  # Moze byc 1 dla durability (wolniejsze)
innodb_buffer_pool_size=1G        # ~70% RAM serwera

# --- Replikacja ---
# Wylacz binary log jezeli tylko Galera (oszczednosc dysku)
# skip-log-bin

# Przydatne dla debugowania Galery
wsrep_log_conflicts=ON

Bootstrapping — uruchamianie klastra po raz pierwszy

# KROK 1: Na wezle 1 (tylko pierwszy raz lub po pelnym shutdown klastra)
# --wsrep-new-cluster tworzy nowy klaster z tego wezla
sudo galera_new_cluster
# lub:
sudo mysqld_safe --wsrep-new-cluster &

# Sprawdz status na wezle 1
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%';"
# wsrep_cluster_size = 1 (tylko ten wezel)
# wsrep_local_state_comment = Synced

# KROK 2: Na wezle 2 — dolaczenie do klastra
sudo systemctl start mariadb
# Wezel automatycznie polaczy sie z wezlem 1 i wykona SST/IST

# Sprawdz status na wezle 2
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
# wsrep_cluster_size = 2

# KROK 3: Na wezle 3
sudo systemctl start mariadb
# Po chwili:
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
# wsrep_cluster_size = 3 — klaster jest gotowy!

# Stworzenie uzytkownika SST (dla mariabackup — wymagany na wezle 1)
mysql -u root -p -e "
CREATE USER 'galera_sst'@'localhost' IDENTIFIED BY 'strong_password_here';
GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'galera_sst'@'localhost';
FLUSH PRIVILEGES;"

Monitoring klastra — kluczowe zmienne wsrep

# Pelny status klastra
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%';" | grep -E \
  "wsrep_cluster_size|wsrep_cluster_status|wsrep_local_state_comment|wsrep_flow_control|wsrep_ready"

# Najwazniejsze zmienne:
# wsrep_cluster_size = 3         (liczba wezlow, powinna byc = N)
# wsrep_cluster_status = Primary (Primary = ok, Non-Primary = brak kworum!)
# wsrep_local_state_comment = Synced (Synced = ok, Joining/Donor = synchronizacja)
# wsrep_ready = ON               (czy wezel przyjmuje zapytania)
# wsrep_flow_control_paused      (dlugi pause = wezel nie nadaza, problem z hardware)

# Monitorowanie konfliktow certyfikacji (deadlock-i)
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_local_cert_failures';"

# Skrypt do monitoringu (Nagios/Zabbix/Prometheus)
#!/bin/bash
STATUS=$(mysql -u monitor -pmonitor_pass -e "SHOW STATUS LIKE 'wsrep_cluster_size';" \
  --skip-column-names -s 2>/dev/null | awk '{print $2}')
if [ "$STATUS" != "3" ]; then
  echo "CRITICAL: Galera cluster size = $STATUS (expected 3)"
  exit 2
fi
echo "OK: Galera cluster size = $STATUS"
exit 0

Galera vs klasyczna replikacja — porównanie

Cecha Galera Cluster Master-Slave (GTID)
Tryb zapisu Multi-master (każdy węzeł) Single-master (tylko master)
Typ replikacji Synchroniczna Asynchroniczna
Replication lag Brak (transakcje commit atomowo) Może być od milisekund do minut
Failover Automatyczny, transparentny Ręczny (lub zewnętrzny: MHA, orchestrator)
Wymagania sieciowe Niskie latencje (<1ms idealne) Toleruje większe opóźnienia
Konflikty zapisów Deadlock error dla klienta Brak (tylko jeden master)
Min. węzłów 3 (kworum) 2 (master + slave)
Złożoność Wyższa Niższa

Najczęstsze pytania

Czym jest Galera Cluster i dlaczego warto go używać? +
Galera Cluster to synchroniczna replikacja multi-master dla MariaDB i MySQL. Każdy węzeł może obsługiwać zarówno odczyty jak i zapisy, a wszystkie zmiany są natychmiast replikowane do wszystkich węzłów (write-set replication). Eliminuje problem opóźnień replikacji (replication lag) typowy dla klasycznej replikacji master-slave. Używa się go dla aplikacji wymagających wysokiej dostępności — awaria jednego węzła nie przerywa działania bazy danych.
Co to jest wsync (wsrep) w Galera Cluster? +
wsrep (Write Set Replication) to API definiujące protokół replikacji Galery. wsync to implementacja wsrep używana przez Galera Cluster. Transakcje są przesyłane między węzłami jako write-sets (zestawy zmian) i zatwierdzane atomowo na wszystkich węzłach jednocześnie lub odrzucane. Mechanizm certyfikacji wykrywa konflikty: jeśli dwie transakcje modyfikują te same wiersze, jedna z nich zostaje odrzucona i klient widzi błąd deadlock.
Jak działa SST i IST w Galera? +
SST (State Snapshot Transfer) — pełna synchronizacja węzła, który był offline zbyt długo lub jest nowy w klastrze. Wymaga transferu całej bazy (może zająć godziny dla dużych baz). Metody SST: rsync (blokuje donor), xtrabackup (nie blokuje, wymaga Percona XtraBackup), mariabackup. IST (Incremental State Transfer) — przyrostowa synchronizacja gdy węzeł był offline krótko, z buforu gcache. Jest szybki i nie blokuje donora. Galera automatycznie wybiera SST lub IST.
Co to jest split-brain w Galera Cluster i jak mu zapobiegać? +
Split-brain to sytuacja gdy sieć pomiędzy węzłami ulega awarii i każda partycja uważa się za prawidłowy klaster, kontynuując przyjmowanie zapisów — prowadzi do rozbieżności danych. Galera zapobiega temu przez kworum: węzeł (lub grupa węzłów) kontynuuje działanie tylko jeśli ma ponad 50% głosów klastra. Dlatego minimalna liczba węzłów to 3 (nie 2): przy awarii jednego z trzech, dwa pozostałe mają kworum (2/3 &gt; 50%) i kontynuują działanie.

Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.