Galera ist kein Drop-in-Ersatz: Active-Active in der Praxis

Multi-Master klingt nach der Lösung aller Verfügbarkeitsprobleme. Warum sich ein Galera-Cluster anders verhält als eine einzelne MariaDB — und wie man Anwendungen darauf vorbereitet.

Der Wunsch ist verständlich: jede Datenbank-Node nimmt Schreibzugriffe an, der Ausfall eines Knotens ist ein Nicht-Ereignis, kein Failover-Skript, kein Replikations-Lag. Genau das liefert Galera — synchrone Multi-Master-Replikation für MariaDB. Der Haken: Wer seine Anwendung unverändert daraufsetzt, lernt die Unterschiede in Produktion kennen. Besser vorher.

Zertifizierung statt Sperren

Galera löst Schreibkonflikte optimistisch: Jeder Knoten führt Transaktionen lokal aus und lässt sie beim Commit clusterweit zertifizieren. Schreiben zwei Knoten gleichzeitig dieselbe Zeile, gewinnt einer — der andere bekommt einen Deadlock-Fehler, den es auf einer Einzel-Instanz so nie gab. Anwendungen brauchen deshalb Commit-Retry-Logik. Das ist wenig Code, aber er muss existieren.

Hot Rows: der klassische Stolperstein

Zähler-Zeilen, Lagerbestände, "letzter Login"-Spalten — alles, was viele Transaktionen gleichzeitig anfassen, wird im Multi-Master-Betrieb zum Konfliktherd. Die Muster dagegen sind bekannt: solche Schreiblasten auf einen Knoten routen, Zähler in Queues oder Redis auslagern, Updates batchen. Ein Readiness-Check vor der Migration findet diese Stellen zuverlässig.

Große Transaktionen und lange Läufe

Die Zertifizierung verschickt Write-Sets ans ganze Cluster — riesige Transaktionen (Massen-Imports, ALTER auf großen Tabellen) blockieren dabei alle. Die Lösung: Importe in Häppchen, Schema-Änderungen mit Rolling-Verfahren, und Limits, die Ausreißer früh stoppen statt spät.

Quorum: warum drei Knoten das Minimum sind

Ein Cluster aus zwei Knoten kann bei einer Netztrennung nicht entscheiden, wer die Wahrheit ist — beide würden weiterschreiben, und beim Wiedersehen gäbe es zwei Datenstände. Deshalb: immer eine ungerade Stimmenzahl, drei Knoten oder zwei plus Arbitrator, sinnvoll über Zonen verteilt. Split-Brain ist kein Restrisiko, sondern eine Designfrage.

Der Proxy macht das Failover unsichtbar

Vor dem Cluster gehört eine Proxy-Schicht (HAProxy oder MaxScale) mit Health Checks: Sie nimmt kranke Knoten aus der Rotation, kann Lese- und Schreiblast trennen und gibt der Anwendung eine einzige, stabile Adresse. Erst damit wird aus "der Cluster lebt noch" ein "niemand hat etwas gemerkt".

Als Managed Service bekommen Sie den Galera-Cluster fertig betrieben — inklusive Readiness-Check Ihrer Anwendung vor dem Umstieg. Denn Active-Active ist großartig, wenn man es respektiert, und lehrreich, wenn nicht.