Galera Cluster: Multi-Master-Setup und seine Fallstricke

1. Was Galera Cluster anders macht

Galera Cluster unterscheidet sich fundamental von klassischer MySQL-Replikation: statt eines einzelnen Writers mit asynchron nachziehenden Replikaten erlaubt Galera Schreibzugriffe auf jedem Knoten gleichzeitig, synchron abgesichert über eine Gruppenkommunikation zwischen allen Mitgliedern. Jeder Knoten ist gleichzeitig Master, und eine Transaktion gilt erst als committed, wenn sie auf allen Knoten erfolgreich zertifiziert wurde. Das ist der Kern dessen, was Galera als echtes Multi-Master-System auszeichnet.

Für Anwendungen bedeutet das: ein Failover eines einzelnen Knotens ist für den Rest des Clusters praktisch unsichtbar, weil die verbleibenden Knoten ohnehin bereits denselben Datenstand halten. Gleichzeitig bringt dieses Modell Einschränkungen mit, die bei klassischer asynchroner Replikation nicht existieren: Schreibkonflikte zwischen Knoten, ein Quorum-Mechanismus gegen Split-Brain und ein Flow-Control-System, das die Cluster-Geschwindigkeit an den langsamsten Knoten anpasst. Wer Galera Cluster einsetzt, tauscht Replikationslag gegen neue, aber gut verstandene Komplexität.

2. Certification-based Replication verstehen

Der Mechanismus hinter Galera Cluster heisst Certification-based Replication und funktioniert grundlegend anders als klassisches Zwei-Phasen-Commit. Eine Transaktion wird lokal auf dem Knoten ausgeführt, an dem sie gestartet wurde, und erst beim Commit-Versuch als Writeset an alle Knoten der Gruppe verteilt. Jeder Knoten prüft dann unabhängig, ob dieses Writeset mit bereits zertifizierten Transaktionen aus derselben Zeitspanne kollidiert, etwa weil dieselbe Zeile gleichzeitig auf zwei Knoten geändert wurde.

Kollidiert das Writeset nicht, wird die Transaktion auf allen Knoten angewendet und gilt als zertifiziert. Kollidiert es, schlägt die Transaktion auf dem Knoten fehl, der die Zertifizierung zuletzt gewinnt, mit einem klassischen Deadlock-Fehler, den die Anwendung wie einen regulären Lock-Konflikt behandeln und per Retry wiederholen muss. Dieser optimistische Ansatz vermeidet verteiltes Locking über das Netzwerk, verlagert die Verantwortung für Konfliktbehandlung aber in die Anwendungsschicht.

3. Cluster-Setup: drei Knoten aufsetzen

Ein produktionsfähiger Galera Cluster benötigt aus Quorum-Gründen mindestens drei Knoten, da eine gerade Anzahl bei einer Netzwerkpartition kein eindeutiges Mehrheitsergebnis liefert. Jeder Knoten benötigt in der my.cnf dieselbe Cluster-Adresse, einen eindeutigen Knotennamen und die Angabe des Replikationsproviders, meist die Galera-Bibliothek libgalera_smm.so.

Der erste Knoten wird mit dem speziellen Bootstrap-Befehl gestartet, der einen neuen Cluster initialisiert, während alle weiteren Knoten sich über die Cluster-Adresse dem bereits laufenden Cluster anschließen und automatisch einen vollständigen Datenabgleich anfordern. Dieser Ablauf muss in genau dieser Reihenfolge erfolgen, da ein gleichzeitiger Bootstrap mehrerer Knoten zu getrennten, inkompatiblen Clustern führt.

# my.cnf: Galera Cluster Grundkonfiguration (auf allen drei Knoten identisch,
# ausser wsrep_node_address und wsrep_node_name)
[mysqld]
wsrep_on                  = ON
wsrep_provider             = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name         = shop_cluster
wsrep_cluster_address      = gcomm://10.0.1.10,10.0.1.11,10.0.1.12
wsrep_node_address         = 10.0.1.10
wsrep_node_name            = node1
wsrep_sst_method           = xtrabackup-v2
wsrep_sst_auth              = sst_user:sst_password
binlog_format               = ROW
default_storage_engine      = InnoDB
innodb_autoinc_lock_mode    = 2

4. State Snapshot Transfer im Vergleich

Wenn ein neuer Knoten einem laufenden Galera Cluster beitritt, muss er zunächst einen vollständigen Datenabgleich erhalten, den State Snapshot Transfer, kurz SST. Galera unterstützt mehrere SST-Methoden mit unterschiedlichen Kompromissen zwischen Geschwindigkeit und Verfügbarkeit des liefernden Knotens während der Uebertragung. Die Wahl der Methode wird über wsrep_sst_method festgelegt und sollte für produktive Cluster bewusst getroffen werden.

In der Praxis ist xtrabackup-v2 die empfohlene Methode für produktive Umgebungen, weil sie im Gegensatz zu mysqldump und rsync keinen blockierenden Zustand auf dem liefernden Knoten erzwingt und dieser während des gesamten Transfers weiter Schreibzugriffe bedienen kann. Bei sehr großen Datenbanken im Terabereich sollte zusätzlich eingeplant werden, dass ein vollständiger SST je nach Netzwerkbandbreite mehrere Stunden dauern kann.

5. Schreibkonflikte erkennen und behandeln

Schreibkonflikte sind in einem Galera Cluster kein Fehlerfall, sondern ein erwartetes Verhalten bei parallelen Schreibzugriffen auf mehreren Knoten. Greifen zwei Transaktionen auf unterschiedlichen Knoten nahezu gleichzeitig auf dieselbe Zeile zu, gewinnt die Transaktion, die zuerst erfolgreich zertifiziert wird, und die andere erhält einen Fehler zurück, der sich für die Anwendung wie ein klassischer InnoDB-Deadlock verhält.

Anwendungen, die gegen einen Galera Cluster schreiben, müssen deshalb zwingend eine Retry-Logik für diese Fehlerklasse implementieren, genau wie bei regulären Deadlocks. In der Praxis reduziert sich die Konfliktrate erheblich, wenn Schreibzugriffe pro Tabellenbereich möglichst auf einen bevorzugten Knoten konzentriert werden, statt Schreiblast gleichmäßig über alle Knoten zu verteilen, auch wenn das dem Multi-Master-Gedanken zunächst widerspricht.

-- Typischer Zertifizierungskonflikt aus Anwendungssicht
UPDATE inventory SET stock = stock - 1 WHERE sku = 'ABC-123';
-- ERROR 1213 (40001): Deadlock found when trying to get lock;
-- try restarting transaction

-- Wsrep-spezifische Fehlercodes zur Unterscheidung prüfen
SHOW VARIABLES LIKE 'wsrep_retry_autocommit';
-- Automatische Retries für Autocommit-Statements konfigurieren
SET GLOBAL wsrep_retry_autocommit = 3;

6. Flow Control und Cluster-Performance

Flow Control ist der Mechanismus, mit dem Galera Cluster verhindert, dass schnelle Knoten so weit vorauseilen, dass ein langsamerer Knoten den Anschluss verliert. Sobald die Warteschlange unangewendeter Writesets auf einem Knoten eine konfigurierte Schwelle überschreitet, signalisiert dieser Knoten den anderen, neue Schreibzugriffe zu pausieren, bis er wieder aufgeholt hat. Das schützt die Konsistenz des Clusters, kann bei einem dauerhaft langsamen Knoten aber die Gesamtperformance aller Knoten spürbar drosseln.

In der Praxis ist ein einzelner unterdimensionierter Knoten, etwa mit langsamerer Festplatte oder schwächerer CPU, die häufigste Ursache für schlechte Cluster-Performance, weil Flow Control das gesamte System auf dessen Tempo verlangsamt. Alle Knoten eines Galera Clusters sollten deshalb möglichst identische Hardware-Ressourcen erhalten, statt heterogene Server zu kombinieren.

-- Flow-Control-Aktivität und Cluster-Größe prüfen
SHOW STATUS LIKE 'wsrep_flow_control_paused';
SHOW STATUS LIKE 'wsrep_flow_control_sent';
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_local_recv_queue';

-- Schwellenwerte für Flow Control anpassen
SET GLOBAL wsrep_provider_options = 'gcs.fc_limit=100; gcs.fc_factor=0.5';

7. Wann Galera passt und wann nicht

Galera Cluster eignet sich besonders gut für Workloads mit vielen kurzen Transaktionen, geografisch verteilten Lesezugriffen und dem Wunsch nach nahezu unsichtbarem Failover, etwa bei OLTP-Systemen mit hohen Verfügbarkeitsanforderungen. Auch für Umgebungen, in denen jeder Knoten sowohl lesen als auch schreiben soll, ohne eine externe Routing-Schicht wie ProxySQL zu benötigen, ist Galera eine sinnvolle Wahl.

Weniger geeignet ist Galera für Workloads mit sehr großen, lang laufenden Transaktionen, hoher Schreibkonkurrenz auf denselben Zeilen von mehreren Knoten aus, oder für Anwendungen, die auf nicht-transaktionale Storage-Engines wie MyISAM angewiesen sind, da Galera ausschließlich mit InnoDB zuverlässig funktioniert. Auch Batch-Jobs mit riesigen Einzeltransaktionen führen durch die synchrone Zertifizierung schnell zu spürbarem Flow Control und sollten in kleinere Chunks aufgeteilt werden.

8. Quorum, Split-Brain und Netzwerkpartitionen

Der Quorum-Mechanismus schützt einen Galera Cluster vor Split-Brain-Situationen, bei denen eine Netzwerkpartition den Cluster in zwei isolierte Gruppen teilt, die unabhängig voneinander widersprüchliche Schreibzugriffe akzeptieren würden. Galera erlaubt Schreibzugriffe nur der Partition, die mehr als die Hälfte aller ursprünglichen Cluster-Mitglieder umfasst. Die kleinere Partition wechselt automatisch in einen schreibgeschützten Zustand, bis die Verbindung wiederhergestellt ist.

Genau deshalb ist eine ungerade Knotenanzahl essenziell: bei zwei Knoten kann keine Seite eine Mehrheit erreichen, sodass beide Partitionen bei einem Netzwerkausfall gesperrt werden. Fällt der gesamte Cluster aus und muss neu gestartet werden, ist ein manueller Bootstrap nötig, bei dem der Knoten mit dem höchsten seqno-Wert als Ausgangspunkt gewählt werden muss, um keine bereits committeten Transaktionen zu verlieren.

# Cluster nach vollständigem Ausfall neu bootstrappen
# Zuerst auf jedem Knoten den höchsten seqno-Wert ermitteln
cat /var/lib/mysql/grastate.dat | grep seqno

# Auf dem Knoten mit dem höchsten seqno den Cluster initialisieren
galera_new_cluster

# Alle weiteren Knoten regulär starten, sie schliessen sich automatisch an
systemctl start mysql

# Cluster-Größe nach dem Neustart prüfen
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

9. Monitoring wichtiger Statusvariablen

Ein produktiver Galera Cluster sollte kontinuierlich anhand seiner wsrep_-Statusvariablen überwacht werden, da klassische MySQL-Metriken allein den Clusterzustand nicht ausreichend abbilden. Besonders wichtig sind wsrep_cluster_status, das den Wert Primary zeigen muss, sowie wsrep_local_state_comment, das den Synchronisationszustand des einzelnen Knotens beschreibt.

Ein Knoten im Zustand Donor/Desynced liefert gerade einen State Snapshot Transfer und sollte in dieser Zeit nicht für Anwendungslast genutzt werden, weshalb eine vorgeschaltete Routing-Schicht wie ProxySQL diesen Zustand aktiv aus dem Health Check ausschließen sollte. Alerting auf wsrep_cluster_size unterhalb der erwarteten Knotenanzahl und auf anhaltende Flow-Control-Pausen gehört in jedes produktive Monitoring-Setup für Galera.

-- Zentrale Galera-Statusvariablen für Monitoring
SHOW STATUS LIKE 'wsrep_cluster_status';    -- Primary erwartet
SHOW STATUS LIKE 'wsrep_cluster_size';      -- Anzahl aktiver Knoten
SHOW STATUS LIKE 'wsrep_local_state_comment'; -- Synced erwartet
SHOW STATUS LIKE 'wsrep_ready';             -- ON erwartet
SHOW STATUS LIKE 'wsrep_local_cert_failures'; -- Zertifizierungskonflikte

10. Zusammenfassung

Galera Cluster ersetzt asynchrone Replikation durch synchrone Certification-based Replication und erlaubt echte Multi-Master-Schreibzugriffe. Der Preis dafür sind Schreibkonflikte, die per Retry-Logik behandelt werden müssen, Flow Control, das die Cluster-Geschwindigkeit an den langsamsten Knoten koppelt, und ein Quorum-Mechanismus, der eine ungerade Knotenanzahl voraussetzt.

Am besten funktioniert Galera bei kurzen Transaktionen, gleichmäßig dimensionierter Hardware auf allen Knoten und einer Anwendung, die auf Zertifizierungskonflikte mit Retry reagiert. Für sehr grosse Batch-Transaktionen oder stark heterogene Cluster-Hardware ist klassische asynchrone Replikation oder eine andere Architektur oft die bessere Wahl.

11. FAQ: Galera Cluster Multi-Master-Setup