Was ich gerne vor meinem ersten MariaDB-Galera-Cluster gewusst hätte

Das Verkaufsargument (Pitch) für Galera Cluster ist unglaublich verlockend: mehrere MariaDB-Knoten (Nodes), alle vollständig beschreibbar, alle absolut synchron, keine Replikationsverzögerung (Lag), keine Panik mehr bei der Frage "Welcher Node hat eigentlich die aktuellsten Daten?". All das stimmt tatsächlich.

Was in diesem Pitch jedoch absolut nicht betont wird, ist die Tatsache, dass "synchron" und "Multi-Master" mit brutalen Konsequenzen einhergehen, die sich in der echten Produktion zeigen – und nicht in einer sterilen Demo mit zwei Nodes und absolut keinem echten Traffic. Nichts davon ist ein Grund, Galera zu meiden, aber es sind absolut Dinge, für die ich vom allerersten Tag an richtig konfiguriert hätte, wenn ich sie vorher gewusst hätte.

Quorum bedeutet: Drei Nodes sind das absolute Minimum

Galera nutzt strikt ein Quorum, um zu entscheiden, ob ein Node oder eine Gruppe von Nodes nach einer Netzwerkunterbrechung (Network Split) weiterarbeiten darf. Eine Mehrheit der Nodes muss sich physisch gegenseitig sehen können.

Bei zwei Nodes bedeutet der Verlust eines jeden, dass der verbleibende Node buchstäblich keine Mehrheit mehr bilden kann und augenblicklich aufhört, Schreibvorgänge (Writes) zu akzeptieren. Zwei Nodes geben Ihnen Replikation, keine Hochverfügbarkeit (High Availability). Drei ist das praktische Minimum. Allerdings muss dieser dritte Node nicht ansatzweise so leistungsstark sein wie die anderen beiden. Ein winziger "Arbitrator"-Node (der garbd, den leichtgewichtigen Arbitrator-Daemon von Galera, nutzt) kann rein dazu dienen, das Quorum aufrechtzuerhalten, ohne überhaupt eine vollständige Datenkopie vorhalten zu müssen.

Jeder Schreibvorgang wartet auf den langsamsten Node

Synchrone Replikation bedeutet, dass ein Commit erst dann bestätigt (acknowledged) wird, wenn alle Nodes ihn explizit zertifiziert haben. Das bedeutet, dass die Schreibperformance Ihres Clusters strikt durch den langsamsten Node und die absolut schlechteste Netzwerklatenz zwischen Ihren Nodes begrenzt ist.

Das ist völlig in Ordnung, wenn alle Nodes im exakt selben Rechenzentrum stehen und die Latenz unter einer Millisekunde liegt. Es wird jedoch schmerzhaft spürbar, wenn jemand vorschlägt, einen Galera-Node in einer völlig anderen Region "aus Redundanzgründen" zu platzieren. Jeder einzelne Schreibvorgang im gesamten Cluster wartet nun auf den Roundtrip zu diesem weit entfernten Node, und der Schreibdurchsatz des Clusters sinkt dramatisch ab, um sich dem anzupassen. Geografische Verteilung ist mit Galera absolut machbar, aber das ist eine bewusste architektonische Entscheidung, in die man nicht einfach unbedacht hineinstolpern sollte.

Schema-Änderungen brauchen einen Plan, nicht einfach ein ALTER TABLE

Ein simples ALTER TABLE auf einer gigantischen Tabelle in Galera kann das gesamte Cluster für die Dauer der Änderung gewaltsam sperren (locken). Jeder Node wendet es standardmäßig über "Total Order Isolation" an und blockiert damit clusterweit alle Schreibvorgänge komplett, bis es vollständig abgeschlossen ist.

Für alles, was über eine winzige Tabelle hinausgeht, ist Rolling Schema Upgrade (RSU) der sehr viel bessere Ansatz. Sie wenden die Änderung auf exakt einen Node nach dem anderen an. Während dieser Node die Änderung verarbeitet, ist er temporär vom Cluster entkoppelt (desynced):

SET SESSION wsrep_OSU_method='RSU';
ALTER TABLE large_table ADD COLUMN new_field VARCHAR(255);

Wiederholen Sie das sorgfältig pro Node. Der Node, der das Alter-Kommando ausführt, ist kurzzeitig nicht synchron (und sollte idealerweise in diesem Zeitfenster aktiv aus der Rotation des Loadbalancers genommen werden), aber der Rest des Clusters bedient den Traffic währenddessen völlig normal weiter. Das erste Mal, als ich ein routinemäßiges ALTER TABLE auf einer Tabelle mit mehreren Millionen Zeilen mit der Standardmethode ausführte, pausierte das gesamte Cluster für die komplette Dauer – was ein unglaublich denkwürdiger Weg war, diese Lektion zu lernen.

wsrep_local_state_comment ist die eine Statuszeile, die wirklich zählt

Galera-Nodes können aus Sicht eines Linux-Prozesses "up" sein, ohne tatsächlich Teil eines funktionierenden Clusters zu sein. Sie könnten gerade beitreten (Joining), als Datenquelle dienen (Donor), desynchronisiert sein oder in einem harten Fehlerzustand feststecken. Das mit Abstand Nützlichste, was man prüfen kann – besonders direkt nach dem Neustart eines Nodes – ist dies:

SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_local_state_comment sollte stolz Synced ausgeben, und die wsrep_cluster_size sollte perfekt mit der Anzahl der Nodes übereinstimmen, die Sie erwarten. Ein Node, der nach einem Absturz neu gestartet ist und aktuell Joining oder Donor/Desynced anzeigt, steckt mitten in der Wiederherstellung. Er führt möglicherweise gerade einen massiven State-Transfer von einem anderen Node durch (was ein eigenes schweres Last-Ereignis ist, von dem man wissen sollte) und ist noch nicht bereit für Traffic – auch wenn MariaDB selbst bereits fröhlich auf eine Basisverbindung antwortet.

Nichts davon ist ein Grund, Galera nicht zu nutzen

Jedes einzelne dieser Dinge ist handhabbar (manageable), sobald man weiß, dass es existiert. Nutzen Sie drei Nodes (oder zwei plus einen Arbitrator) für ein echtes Quorum. Halten Sie die Nodes physisch nah beieinander im Netzwerk. Verwenden Sie RSU für Schema-Änderungen bei allem, was nicht trivial ist. Prüfen Sie wsrep_local_state_comment als festen Bestandteil jedes Health-Checks oder nach jedem Neustart.

Galera liefert das Versprechen der synchronen Multi-Master-Replikation absolut ab. Der Haken an der Sache ist schlichtweg, dass "synchron" und "Multi-Master" exakt die Eigenschaften sind, die diese vier Punkte überhaupt erst so relevant machen. Sie sind einfach der Preis für genau das Feature, das Galera überhaupt erst so unglaublich nützlich macht.