Was ich vor meinem ersten MariaDB-Galera-Cluster gerne gewusst hätte
Das Versprechen von Galera Cluster klingt verlockend: mehrere MariaDB-Nodes, alle schreibbar, alle synchron im Gleichschritt, keine Replikationsverzögerung, keine Frage, welcher Node die aktuellsten Daten hat. All das stimmt. Was der Pitch nicht betont, ist, dass "synchron" und "Multi-Master" beide Konsequenzen mitbringen, die sich in Produktion zeigen, nicht in einer Demo mit zwei Nodes und ohne echten Traffic. Keiner dieser Punkte ist ein Grund, Galera zu meiden, aber es sind Dinge, die ich von Anfang an mit eingeplant hätte, wenn ich sie gekannt hätte.
Quorum bedeutet: drei Nodes sind das eigentliche Minimum
Galera nutzt Quorum, um zu entscheiden, ob ein Node oder eine Gruppe von Nodes nach einem Netzwerk-Split weiterarbeiten darf, eine Mehrheit der Nodes muss sich gegenseitig sehen können. Mit zwei Nodes bedeutet der Ausfall eines davon, dass der verbleibende keine Mehrheit bilden kann und keine Schreibvorgänge mehr annimmt, zwei Nodes geben einem Replikation, nicht Hochverfügbarkeit. Drei ist das praktische Minimum, und der dritte Node muss nicht so leistungsfähig sein wie die anderen beiden, ein kleinerer "Arbitrator"-Node (mit garbd, Galeras leichtgewichtigem Arbitrator-Daemon) kann rein dazu dienen, das Quorum aufrechtzuhalten, ohne eine vollständige Datenkopie zu halten.
Jeder Schreibvorgang wartet auf den langsamsten Node
Synchrone Replikation bedeutet, dass ein Commit erst bestätigt wird, wenn alle Nodes ihn zertifiziert haben, das heißt, der Schreibdurchsatz des Clusters ist durch den langsamsten Node und die Netzwerklatenz zwischen den Nodes begrenzt. Das ist kein Problem, solange alle Nodes im selben Rechenzentrum mit Latenzen im Sub-Millisekundenbereich sitzen. Es wird sehr spürbar, sobald jemand vorschlägt, "zur Redundanz" einen Galera-Node in eine andere Region zu legen, jeder Schreibvorgang im gesamten Cluster wartet jetzt auf einen Roundtrip zu diesem Node, und der Schreibdurchsatz des Clusters sinkt entsprechend. Geografische Verteilung ist mit Galera möglich, aber das ist eine bewusste Architekturentscheidung, in die man nicht versehentlich hineinrutschen sollte.
Schema-Änderungen brauchen einen Plan, nicht nur ein ALTER TABLE
Ein einfaches ALTER TABLE auf einer großen Tabelle kann in Galera den gesamten Cluster für die Dauer der Änderung blockieren, jeder Node wendet es per Default über Total Order Isolation an und blockiert dabei Schreibvorgänge im gesamten Cluster, bis es fertig ist. Für alles, was über eine kleine Tabelle hinausgeht, ist Rolling Schema Upgrade (RSU) der bessere Ansatz: die Änderung Node für Node anwenden, wobei dieser Node während der Bearbeitung vorübergehend vom Cluster desynchronisiert wird:
SET SESSION wsrep_OSU_method='RSU';
ALTER TABLE grosse_tabelle ADD COLUMN neues_feld VARCHAR(255);
Pro Node wiederholen. Der Node, auf dem das Alter läuft, ist kurz nicht synchron (und sollte idealerweise währenddessen aus der Rotation des Load Balancers genommen werden), aber der Rest des Clusters bedient den Traffic währenddessen normal weiter. Als ich das erste Mal ein routinemäßiges ALTER TABLE auf einer Tabelle mit mehreren Millionen Zeilen mit der Standardmethode ausgeführt habe, pausierte der gesamte Cluster für die Dauer der Änderung, eine einprägsame Art, das zu lernen.
wsrep_local_state_comment ist die Statuszeile, die zählt
Galera-Nodes können aus Prozesssicht "laufen", ohne tatsächlich Teil eines funktionierenden Clusters zu sein, joining, donor/desynced, oder in einem Fehlerzustand. Das mit Abstand Nützlichste, das man prüfen sollte, besonders direkt nach einem Neustart eines Nodes:
SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_cluster_size';
wsrep_local_state_comment sollte Synced anzeigen, und wsrep_cluster_size sollte mit der erwarteten Anzahl der Nodes übereinstimmen. Ein Node, der nach einem Absturz neu gestartet ist und Joining oder Donor/Desynced zeigt, befindet sich mitten in der Wiederherstellung (möglicherweise mit einem vollständigen State Transfer von einem anderen Node, was selbst ein Load-Event ist, das man kennen sollte), nicht bereit für Traffic, auch wenn MariaDB selbst auf eine einfache Verbindung schon reagiert.
Nichts davon ist ein Grund, Galera nicht zu nutzen
Jeder dieser Punkte ist beherrschbar, sobald man weiß, dass er existiert: drei Nodes (oder zwei plus ein Arbitrator) für echtes Quorum, Nodes nah beieinander im Netzwerk halten, RSU für Schema-Änderungen an allem Nicht-Trivialen nutzen, und wsrep_local_state_comment als Teil jedes Health-Checks oder nach jedem Neustart prüfen. Galera hält tatsächlich, was es für synchrone Multi-Master-Replikation verspricht, der Haken ist nur, dass "synchron" und "Multi-Master" genau die Eigenschaften sind, die diese vier Punkte wichtig machen, sie sind der Preis für das, was Galera überhaupt erst lohnenswert macht.