Group Replication: Konflikterkennung bei Multi-Primary-Setups verstehen

1. Certification-based Conflict Detection: das Grundprinzip

Group Replication erlaubt jedem Knoten, Transaktionen lokal auszuführen, ohne vorab auf eine Sperre über das gesamte Netzwerk zu warten. Erst beim Commit wird die Transaktion über ein Paxos-basiertes Gruppenkommunikationsprotokoll an alle Mitglieder verteilt und dort gegen bereits erfolgreich zertifizierte Transaktionen geprüft. Dieses optimistische Verfahren vermeidet die Latenzkosten eines synchronen Sperr-Roundtrips vor jeder Schreiboperation, verlagert das Konfliktrisiko aber vom Zeitpunkt des Schreibens auf den Zeitpunkt des Commits.

Der Begriff Zertifizierung beschreibt genau diesen nachträglichen Abgleich: Jeder Knoten prüft unabhängig, ob die von ihm empfangene Transaktion mit Zeilen kollidiert, die zwischen dem Start dieser Transaktion und ihrem Commit bereits von einer anderen, schneller zertifizierten Transaktion verändert wurden. Da alle Knoten dieselbe deterministische Zertifizierungslogik anwenden, kommen sie unabhängig voneinander zum selben Ergebnis, ohne dass eine zentrale Koordinationsinstanz nötig wäre.

2. Wie ein Write Set gebildet wird

Ein Write Set ist eine kompakte Darstellung aller Zeilen, die eine Transaktion verändert hat, kodiert als Hash-Werte der Primärschlüssel der betroffenen Zeilen kombiniert mit der jeweiligen Tabelle. Genau aus diesem Grund verlangt Group Replication zwingend einen Primärschlüssel auf jeder replizierten Tabelle: Ohne eindeutigen Schlüssel lässt sich keine stabile, vergleichbare Zeilenidentität für die Zertifizierung bilden, und Group Replication verweigert entsprechende Transaktionen mit einer expliziten Fehlermeldung.

Das Write Set wird nicht aus dem SQL-Text der Transaktion gebildet, sondern aus den tatsächlich betroffenen Zeilen nach Anwendung aller WHERE-Bedingungen. Zwei Transaktionen, die syntaktisch völlig unterschiedliche UPDATE-Statements enthalten, aber am Ende dieselbe Zeile verändern, erzeugen überlappende Write Sets und werden daher als potenziell konfliktbehaftet erkannt, unabhängig von der jeweiligen SQL-Formulierung.

3. Der Zertifizierungsprozess Schritt für Schritt

Beim Commit sendet der ausführende Knoten das Write Set zusammen mit den Binlog-Events über das Gruppenkommunikationsprotokoll an alle Mitglieder, inklusive sich selbst. Jeder Knoten vergleicht dieses Write Set mit einer lokal gehaltenen Historie bereits zertifizierter, aber noch nicht vollständig angewendeter Transaktionen. Überschneidet sich das neue Write Set mit keiner dieser vorangegangenen Transaktionen, gilt die Transaktion als erfolgreich zertifiziert und wird zur Anwendung freigegeben.

Findet sich eine Überschneidung mit einer bereits zertifizierten, aber zeitlich vorher eingetroffenen Transaktion, wird die neu ankommende Transaktion abgelehnt. Entscheidend ist dabei die Reihenfolge, in der das Gruppenkommunikationsprotokoll die Nachrichten global konsistent zustellt, nicht die tatsächliche Uhrzeit auf den einzelnen Servern. Diese globale Zustellreihenfolge ist der eigentliche Kern des Paxos-basierten Protokolls und garantiert, dass alle Knoten unabhängig zur selben Entscheidung kommen.

4. Typisches Konfliktszenario: gleichzeitige Updates auf zwei Knoten

Das klassische Beispiel: Zwei Anwendungsinstanzen verbinden sich im Multi-Primary-Modus mit zwei unterschiedlichen Knoten und aktualisieren nahezu zeitgleich denselben Warenbestand-Datensatz, etwa UPDATE cataloginventory_stock_item SET qty = qty - 1 WHERE item_id = 4711. Beide Transaktionen lesen und verändern lokal erfolgreich, beide werden lokal committet und an die Gruppe verteilt. Nur eine der beiden übersteht die Zertifizierung, die andere wird mit einem Zertifizierungsfehler zurückgerollt, nachdem sie dem Client bereits als lokal erfolgreich signalisiert wurde.

Dieses Verhalten unterscheidet sich fundamental von einem klassischen Deadlock innerhalb eines einzelnen Servers, bei dem der Konflikt bereits vor dem Commit erkannt wird. Bei Group Replication erfährt die Anwendung erst nach dem scheinbar erfolgreichen Commit, dass die Transaktion doch nicht durchgekommen ist, was Anwendungscode ohne entsprechende Vorbereitung leicht in einen inkonsistenten Zustand bringen kann.

-- Knoten A und Knoten B führen nahezu zeitgleich aus:
START TRANSACTION;
UPDATE cataloginventory_stock_item SET qty = qty - 1 WHERE item_id = 4711;
COMMIT;
-- Eine der beiden Transaktionen scheitert erst nach dem lokalen COMMIT mit:
-- ERROR 3101 (HY000): Plugin instructed the server to rollback the
-- current transaction (Zertifizierungsfehler)

5. Was bei einem Konflikt passiert: Rollback und Fehlerbehandlung

Scheitert die Zertifizierung, führt Group Replication auf dem betroffenen Knoten einen automatischen Rollback der lokal bereits committeten Transaktion durch. Der Client, der den ursprünglichen COMMIT bereits als erfolgreich zurückgemeldet bekam, muss diesen Fehler über eine separate Fehlermeldung im weiteren Verlauf der Verbindung erkennen, üblicherweise als Fehlercode 3101, und die gesamte Transaktion selbst erneut ausführen.

Für Anwendungscode bedeutet das, dass jede Schreibtransaktion im Multi-Primary-Betrieb in eine Retry-Schleife eingebettet werden muss, die diesen spezifischen Fehlercode erkennt und die Transaktion mit denselben Ausgangsdaten erneut versucht. Fehlt diese Retry-Logik, verschwinden Schreiboperationen unter Last scheinbar zufällig, ohne dass die Anwendung selbst einen Fehler bemerkt, sofern der ursprüngliche Fehler nicht ordnungsgemäß propagiert wird.

6. Single-Primary vs. Multi-Primary: die Konsequenz für die Anwendungsarchitektur

Im Single-Primary-Modus, dem Standardmodus von Group Replication, akzeptiert ausschließlich ein Knoten Schreibzugriffe, alle anderen Mitglieder werden automatisch schreibgeschützt. Dadurch entstehen zwischen Schreibtransaktionen niemals Zertifizierungskonflikte, weil es keine gleichzeitigen, konkurrierenden Schreiber auf unterschiedlichen Knoten gibt. Die Zertifizierung existiert weiterhin als Mechanismus, greift aber praktisch nie ein, solange kein Failover mit kurzzeitig unklarer Primary-Rolle stattfindet.

Im Multi-Primary-Modus entfällt diese Garantie vollständig, jeder Knoten kann gleichzeitig Ziel von Schreibzugriffen sein, was zwar horizontale Schreibskalierung über mehrere Knoten verspricht, aber jede Anwendung zwingt, mit Zertifizierungskonflikten als normalem Betriebsfall umzugehen. Für die meisten Magento-nahen Anwendungsfälle, bei denen Schreiblast eher schmal, aber konsistenzkritisch ist, etwa Lagerbestände oder Bestellstatus, überwiegt in der Praxis der Single-Primary-Modus als deutlich einfacher zu betreibende Wahl.

7. Wann Multi-Primary trotzdem sinnvoll ist

Multi-Primary lohnt sich vor allem dann, wenn Schreiblast geografisch oder anwendungsseitig so verteilt werden kann, dass unterschiedliche Knoten überwiegend disjunkte Datenbereiche bearbeiten, etwa getrennte Kundengruppen oder unabhängige Tabellenbereiche ohne Zeilenüberschneidung. In solchen Fällen bleibt die tatsächliche Konfliktrate niedrig, obwohl der Modus formal alle Knoten schreibfähig hält.

Wo diese Trennung nicht gelingt, etwa bei zentralen, häufig aktualisierten Zählern wie Lagerbeständen, steigt die Zertifizierungskonfliktrate mit der Schreibfrequenz überproportional an, weil die Wahrscheinlichkeit einer echten Zeilenüberschneidung zwischen zwei parallel arbeitenden Knoten wächst. Anwendungscode muss in diesem Fall nicht nur Retry-Logik implementieren, sondern auch idempotente Schreiboperationen bevorzugen, etwa relative statt absolute Updates, um wiederholte Ausführung nach einem Rollback sicher zu machen.

8. Monitoring von Zertifizierungskonflikten

Group Replication protokolliert Konfliktstatistiken direkt in performance_schema.replication_group_member_stats, insbesondere in der Spalte COUNT_TRANSACTIONS_ROLLBACK_DUE_TO_PRIMARY_TRANSACTION_LIMIT_VIOLATION sowie COUNT_CONFLICTS_DETECTED. Ein kontinuierlich steigender Wert bei COUNT_CONFLICTS_DETECTED ist ein zuverlässiges Frühwarnsignal dafür, dass der Multi-Primary-Modus für das aktuelle Zugriffsmuster nicht gut geeignet ist, lange bevor Nutzer Fehlermeldungen im Frontend bemerken.

Für ein produktives Monitoring-Dashboard lohnt sich eine regelmäßige Abfrage dieser Zähler pro Knoten, kombiniert mit einer Alarmschwelle relativ zur Gesamttransaktionsrate, da eine absolute Konfliktzahl ohne Bezug zum Durchsatz wenig aussagekräftig ist. Ein Anstieg der relativen Konfliktrate über wenige Prozent der Gesamttransaktionen hinweg deutet meist auf ein strukturelles Zugriffsmuster-Problem hin, das sich nicht allein durch Retry-Logik lösen lässt.

SELECT MEMBER_ID, COUNT_CONFLICTS_DETECTED, COUNT_TRANSACTIONS_REMOTE_APPLIED
FROM performance_schema.replication_group_member_stats;

9. Praktische Empfehlung für Tabellen-Design und Retry-Pattern

Für Tabellen, die potenziell im Multi-Primary-Modus beschrieben werden, empfiehlt sich ein Design, das Zeilenüberschneidungen von vornherein reduziert, etwa durch fachliche Partitionierung nach Mandant oder Region statt einer einzigen zentralen Zähltabelle. Wo eine zentrale Zeile unvermeidbar bleibt, wie bei einem globalen Lagerbestand, sollte die Anwendung diese Schreiblast bewusst auf einen einzigen logischen Schreiber begrenzen, auch wenn die Infrastruktur formal Multi-Primary betreibt.

Auf Anwendungsebene hat sich ein generisches Retry-Pattern bewährt, das den Zertifizierungsfehlercode gezielt abfängt, eine kurze randomisierte Wartezeit einlegt und die Transaktion mit frisch gelesenen Ausgangsdaten erneut ausführt, statt die ursprünglichen, möglicherweise veralteten Werte blind erneut zu schreiben. Dieses Muster reduziert nicht nur die Fehlerquote, sondern verhindert auch, dass wiederholte Retries denselben Konflikt in einer Endlosschleife erneut erzeugen.

10. Zusammenfassung

11. FAQ: Konflikterkennung in Group Replication: Das Wichtigste auf einen Blick