MySQL Group Replication für Hochverfügbarkeit

1. Was Group Replication anders macht als klassische Replikation

MySQL Group Replication unterscheidet sich fundamental von klassischer asynchroner oder semi-synchroner Replikation, weil die Gruppenmitglieder nicht in einer starren Quelle-Replica-Hierarchie stehen, sondern über ein Konsensprotokoll gemeinsam entscheiden, welche Transaktionen angewendet werden. Jedes Mitglied kennt den Zustand der gesamten Gruppe, erkennt automatisch, wenn ein Knoten ausfällt, und entfernt ihn aus der aktiven Mitgliedschaft, ohne dass ein externes Tool wie ein Orchestrator diese Entscheidung treffen muss.

Diese Selbstverwaltung ist der zentrale Vorteil von Group Replication gegenüber Setups, die klassische Replikation mit externen Failover-Tools wie Orchestrator oder MHA kombinieren. Statt eines externen Systems, das den Zustand der Datenbank von außen überwacht und im Fehlerfall eingreift, trägt die Gruppe selbst die Verantwortung für Konsistenz und Verfügbarkeit. Das reduziert die Betriebskomplexität, bringt aber eigene Anforderungen an Netzwerklatenz und Gruppengröße mit sich, die vor dem Einsatz verstanden werden müssen.

-- Manual bootstrap of the first Group Replication member (without MySQL Shell)
-- Only set bootstrap_group on the very first node, and only for the startup
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

-- On every additional node: join the existing group, no bootstrap flag
CHANGE REPLICATION SOURCE TO
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'strong-password-here'
  FOR CHANNEL 'group_replication_recovery';
START GROUP_REPLICATION;

2. Das Group Communication System und Konsens

Im Kern von Group Replication steht das Group Communication System, kurz GCS, das auf dem Paxos-basierten Protokoll XCom aufbaut. Jede Transaktion durchläuft vor dem finalen Commit eine gruppenweite Zertifizierung: Die Transaktion wird an alle erreichbaren Mitglieder verteilt, jedes Mitglied prüft, ob sie mit bereits zertifizierten Transaktionen in Konflikt steht, und erst wenn eine Mehrheit der Gruppe zustimmt, gilt die Transaktion als zertifiziert und wird angewendet.

Dieses Mehrheitsprinzip, auch als Quorum bezeichnet, ist der Grund, warum Group Replication ausfallsicher funktioniert, ohne einen einzelnen Koordinator zu benötigen: Solange mehr als die Hälfte der konfigurierten Mitglieder erreichbar ist, kann die Gruppe weiterarbeiten. Fällt die Mehrheit aus, etwa bei einem Netzwerk-Split, der die Gruppe in zwei gleich große Hälften teilt, verweigert die kleinere Partition automatisch weitere Schreiboperationen, um ein Split-Brain-Szenario mit widersprüchlichen Datenständen zu verhindern. Aus diesem Grund werden Gruppen üblicherweise mit einer ungeraden Mitgliederzahl betrieben, meist drei oder fünf Knoten.

# my.cnf configuration for a Group Replication member
[mysqld]
server-id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE
log_bin = binlog
log_slave_updates = ON
binlog_format = ROW

# Group Replication plugin settings
plugin_load_add = 'group_replication.so'
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_start_on_boot = OFF
group_replication_local_address = "10.0.0.1:33061"
group_replication_group_seeds = "10.0.0.1:33061,10.0.0.2:33061,10.0.0.3:33061"
group_replication_bootstrap_group = OFF
group_replication_single_primary_mode = ON
group_replication_enforce_update_everywhere_checks = OFF

3. Single-Primary Modus im Detail

Im Single-Primary Modus, dem empfohlenen Standard für die meisten Anwendungsfälle von Group Replication, akzeptiert nur ein Mitglied der Gruppe Schreiboperationen, während alle anderen Mitglieder automatisch schreibgeschützt sind. Diese Rolle wird von der Gruppe selbst zugewiesen, basierend auf einer internen Wahl nach dem Beitritt oder nach dem Ausfall des aktuellen Primary. Anwendungen müssen nicht wissen, welcher Knoten aktuell Primary ist, weil SELECT @@global.read_only oder die Systemtabelle performance_schema.replication_group_members die aktuelle Rolle jederzeit abfragbar machen.

Der Vorteil des Single-Primary Modus liegt in der einfacheren Konsistenzgarantie: Da alle Schreiboperationen über einen einzigen Knoten laufen, entfallen Schreibkonflikte zwischen mehreren gleichzeitig schreibenden Mitgliedern vollständig. Anwendungen, die aus klassischer Quelle-Replica-Replikation migrieren, finden im Single-Primary Modus ein vertrautes Verhaltensmuster wieder, ergänzt um automatisches Failover, das im klassischen Setup zusätzliche externe Tools erfordert hätte.

4. Multi-Primary Modus und Konfliktbehandlung

Im Multi-Primary Modus akzeptieren alle Mitglieder der Gruppe gleichzeitig Schreiboperationen, was auf den ersten Blick nach höherer Skalierbarkeit klingt, in der Praxis aber erhebliche Sorgfalt bei der Anwendungsarchitektur erfordert. Schreibt Anwendung A eine Zeile auf Mitglied 1, während Anwendung B dieselbe Zeile gleichzeitig auf Mitglied 2 ändert, erkennt die Zertifizierung von Group Replication den Konflikt beim Versuch der Zertifizierung, und eine der beiden Transaktionen wird mit einem Fehler zurückgewiesen, den die Anwendung behandeln muss.

Diese optimistische Konfliktbehandlung bedeutet, dass Anwendungscode auf Zertifizierungsfehler vorbereitet sein muss, typischerweise durch Retry-Logik auf Transaktionsebene. Multi-Primary Modus eignet sich gut für Workloads mit geografisch verteilten Schreibern auf unterschiedlichen, klar getrennten Datenbereichen, etwa wenn jede Region primär in ihre eigenen Tabellen schreibt. Für allgemeine OLTP-Anwendungen mit hoher Schreibkonkurrenz auf denselben Zeilen führt Multi-Primary Modus häufig zu mehr Komplexität, als er an Skalierbarkeit gewinnt.

5. Automatisches Failover in der Gruppe

Fällt das aktuelle Primary-Mitglied im Single-Primary Modus aus, erkennt das Group Communication System den Ausfall über Fehlererkennungsmechanismen mit konfigurierbaren Timeouts, entfernt den Knoten aus der aktiven Gruppenmitgliedschaft und wählt automatisch ein neues Primary aus den verbleibenden Mitgliedern. Dieser gesamte Prozess läuft typischerweise innerhalb weniger Sekunden ab, ohne dass ein Administrator manuell eingreifen muss, was Group Replication gegenüber klassischer Replikation mit manuellem oder extern orchestriertem Failover deutlich vereinfacht.

Wichtig für Anwendungen ist, dass dieses Failover nicht automatisch bedeutet, dass die Anwendung nahtlos weiterläuft: Verbindungen zum ausgefallenen Primary werden unterbrochen und müssen neu aufgebaut werden. Hier kommt der MySQL Router ins Spiel, der die Gruppenmitgliedschaft überwacht und Verbindungen transparent an das jeweils aktuelle Primary weiterleitet, sodass die Anwendung selbst keine Kenntnis über die interne Topologie benötigt.

6. InnoDB Cluster mit MySQL Shell aufbauen

InnoDB Cluster ist die von Oracle bereitgestellte Verwaltungsschicht über Group Replication, die den Aufbau, die Überwachung und die Wartung eines Clusters erheblich vereinfacht. Statt jede Konfigurationsvariable manuell auf jedem Knoten zu setzen, übernimmt die MySQL Shell mit ihrer AdminAPI die Konfiguration und Validierung der Gruppenmitglieder.

// MySQL Shell (JavaScript mode): bootstrap a 3-node InnoDB Cluster
shell> mysqlsh --uri root@10.0.0.1:3306

// Check that this instance meets Group Replication requirements
dba.checkInstanceConfiguration('root@10.0.0.1:3306');

// Create the cluster on the first (seed) node
var cluster = dba.createCluster('productionCluster');

// Add the remaining members, MySQL Shell handles GTID recovery automatically
cluster.addInstance('root@10.0.0.2:3306');
cluster.addInstance('root@10.0.0.3:3306');

// Inspect the current topology and roles
cluster.status();

// Example output excerpt:
// "primary": "10.0.0.1:3306",
// "status": "OK",
// "statusText": "Cluster is ONLINE and can tolerate up to ONE failure."

Die AdminAPI übernimmt bei addInstance automatisch die sogenannte Distributed Recovery: Der neue Knoten gleicht seinen GTID-Stand mit der Gruppe ab und synchronisiert fehlende Transaktionen über klassische asynchrone Replikation, bevor er formal der Group Replication Gruppe beitritt. Das erspart das manuelle Erstellen und Einspielen von Backups, das bei klassischer Replikation notwendig ist.

7. MySQL Router für transparentes Routing

Der MySQL Router sitzt zwischen Anwendung und Cluster und übernimmt die Aufgabe, Verbindungen basierend auf der aktuellen Gruppenrolle weiterzuleiten. Anwendungen verbinden sich mit einem festen Router-Port, üblicherweise 6446 für Read-Write- und 6447 für Read-Only-Verbindungen, ohne die IP-Adressen der einzelnen Cluster-Knoten zu kennen. Fällt das Primary aus und die Gruppe wählt ein neues, erkennt der Router die Änderung automatisch über die Metadaten des InnoDB Cluster und leitet neue Verbindungen an das aktuelle Primary weiter.

Diese Abstraktionsschicht ist der entscheidende Baustein, damit Group Replication für Anwendungen tatsächlich transparent hochverfügbar wirkt. Ohne Router müsste die Anwendung selbst die Gruppenmitgliedschaft abfragen und bei jedem Failover die Verbindungszeichenkette anpassen, was in der Praxis zu Verzögerungen und Fehlerbehandlungscode führt, den der Router vollständig kapselt.

# Bootstrap MySQL Router against the InnoDB Cluster metadata
mysqlrouter --bootstrap root@10.0.0.1:3306 \
  --directory /opt/mysqlrouter \
  --conf-use-gr-notifications

# Resulting mysqlrouter.conf (excerpt): fixed ports for the application
[routing:productionCluster_rw]
bind_address = 0.0.0.0
bind_port = 6446
destinations = metadata-cache://productionCluster/?role=PRIMARY
protocol = classic

[routing:productionCluster_ro]
bind_address = 0.0.0.0
bind_port = 6447
destinations = metadata-cache://productionCluster/?role=SECONDARY
protocol = classic

# Start the router as a service
mysqlrouter --config /opt/mysqlrouter/mysqlrouter.conf

8. Monitoring der Gruppenmitgliedschaft

Der zentrale Ort für das Monitoring von Group Replication ist die Tabelle performance_schema.replication_group_members, die für jedes Mitglied Status, Rolle und Version anzeigt. Ergänzend liefert replication_group_member_stats Details zu Konflikten, Zertifizierungsraten und der Größe der Transaktionswarteschlange, was frühzeitig auf Überlastung eines Mitglieds hinweist, bevor es aus der Gruppe ausgeschlossen wird.

-- Check the health and role of every group member
SELECT member_id, member_host, member_port, member_state, member_role
FROM performance_schema.replication_group_members;

-- Example output:
-- member_id | member_host | member_port | member_state | member_role
-- uuid-1    | 10.0.0.1    | 3306        | ONLINE       | PRIMARY
-- uuid-2    | 10.0.0.2    | 3306        | ONLINE       | SECONDARY
-- uuid-3    | 10.0.0.3    | 3306        | ONLINE       | SECONDARY

-- Inspect certification conflicts and queue size per member
SELECT member_id, count_transactions_in_queue, count_conflicts_detected
FROM performance_schema.replication_group_member_stats;

Ein Zustand, der besondere Aufmerksamkeit verdient, ist member_state = UNREACHABLE, der signalisiert, dass ein Mitglied vom Rest der Gruppe nicht erreicht werden kann, aber noch nicht formal ausgeschlossen wurde. Bleibt dieser Zustand über den konfigurierten group_replication_unreachable_majority_timeout hinaus bestehen, muss die Gruppe entscheiden, ob sie mit reduzierter Mitgliederzahl weiterarbeitet oder Schreiboperationen blockiert, um Konsistenz zu wahren.

9. Single-Primary vs. Multi-Primary im Vergleich

Die Entscheidung zwischen Single-Primary und Multi-Primary Modus bei Group Replication bestimmt maßgeblich die Komplexität der Anwendungsschicht und die erreichbare Schreibskalierung. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

In der Praxis läuft die überwiegende Mehrheit produktiver Group Replication Cluster im Single-Primary Modus, weil die Vorhersagbarkeit des Anwendungsverhaltens meist schwerer wiegt als der theoretische Skalierungsgewinn im Multi-Primary Modus. Multi-Primary lohnt sich vor allem in Szenarien, in denen die Schreiblast bereits architektonisch nach Datenbereichen getrennt ist, etwa bei Multi-Tenant-Systemen mit strikt getrennten Mandanten-Schemas.

10. Zusammenfassung

MySQL Group Replication verlagert die Verantwortung für Konsistenz und Failover von externen Tools direkt in die Datenbank selbst, gesteuert über ein Paxos-basiertes Konsensprotokoll und eine gruppenweite Transaktionszertifizierung. Der Single-Primary Modus bleibt für die meisten Anwendungsfälle die richtige Wahl, weil er das vertraute Verhalten klassischer Replikation mit automatischem Failover kombiniert, ohne Schreibkonflikte in Kauf zu nehmen. Multi-Primary Modus eröffnet zusätzliche Skalierung, verlangt aber Konfliktbehandlung auf Anwendungsebene.

InnoDB Cluster und MySQL Router machen Group Replication für den Praxiseinsatz erheblich zugänglicher, weil sie Setup, Recovery und Verbindungsrouting automatisieren, die andernfalls manuell und fehleranfällig wären. Wer Gruppenmitgliedschaft und Zertifizierungsstatistiken kontinuierlich überwacht, erkennt Probleme, bevor sie zum Ausschluss eines Mitglieds oder zum Verlust des Schreib-Quorums führen.

11. FAQ: MySQL Group Replication