Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Kwiecień 2026 1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. MySQL Galera Cluster # 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 > 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. Contabo VPS z dużą ilością RAM i SSD — idealny pod węzeł Galera Cluster VPS + RAM [Aktywuj rabat →](/out/contabo) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) Mikr.us Budżetowy VPS do nauki i testów Galera Cluster Dev/Test [Aktywuj rabat →](/out/mikrus) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) LH.pl Hosting z zarządzaną MySQL — bez konfiguracji klastra Hosting [Aktywuj rabat →](/out/lh-pl) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/lh-pl) ## Powiązane strony - [MySQL replikacja master-slave](/baza-wiedzy/mysql-replication-master-slave) - [PostgreSQL Streaming Replication](/baza-wiedzy/postgresql-streaming-replication) - [MySQL slow query log i optymalizacja](/baza-wiedzy/mysql-slow-query-log) - [Wszystkie artykuły](/baza-wiedzy/)