MySQL InnoDB Cluster und MySQL Router: Hochverfügbarkeit ohne externe Tools aufsetzen

1. Was InnoDB Cluster ist: Zusammenspiel aus drei Komponenten

InnoDB Cluster ist kein eigenständiges Replikationsprotokoll, sondern eine Orchestrierungsschicht über drei bestehenden Bausteinen. Group Replication übernimmt die eigentliche Datenreplikation zwischen den Knoten über ein Paxos-basiertes Gruppenkommunikationsprotokoll. Die AdminAPI der MySQL Shell stellt eine deklarative Verwaltungsschicht darüber, die Cluster-Konfiguration, Metadatenverwaltung und Instanzverwaltung als konsistente Objektmethoden anbietet, statt einzelne Server-Variablen von Hand zu setzen.

MySQL Router schließlich sitzt als leichtgewichtiger Proxy zwischen Anwendung und Cluster und leitet Verbindungen abhängig von ihrer Rolle automatisch an den aktuellen Primary oder an lesbare Sekundärknoten weiter. Diese drei Komponenten zusammen ergeben eine Lösung, bei der eine Anwendung nur eine einzige, stabile Verbindungsadresse zum Router kennen muss, unabhängig davon, welcher physische Knoten gerade als Primary agiert.

2. Der Unterschied zum manuellen Group-Replication-Setup

Ein manuelles Group-Replication-Setup verlangt, dass auf jedem Knoten einzeln Variablen wie group_replication_group_name, group_replication_local_address und group_replication_group_seeds konsistent gesetzt werden, bevor die Gruppe überhaupt bootstrappen kann. Fehler bei dieser manuellen Abstimmung, etwa eine falsche Seed-Adresse oder eine abweichende UUID für die Gruppe, führen zu schwer diagnostizierbaren Split-Brain-Situationen, die oft erst beim ersten Failover sichtbar werden.

Die AdminAPI kapselt genau diese Fehlerquelle: dba.createCluster() berechnet die notwendigen Group-Replication-Variablen selbst, legt ein Metadata-Schema an, in dem Topologie, Instanzrollen und Router-Registrierungen konsistent gepflegt werden, und prüft bei jedem addInstance() aktiv, ob die neue Instanz kompatibel konfiguriert ist. Diese Vorabprüfungen, etwa auf passenden server_id, aktivierte GTIDs oder korrekte Zeichensätze, verhindern viele Fehler, die bei manueller Konfiguration erst im laufenden Betrieb auffallen.

3. Voraussetzungen: GTID, InnoDB und Server-Konfiguration

InnoDB Cluster setzt GTID-basierte Replikation zwingend voraus, da die AdminAPI intern auf SOURCE_AUTO_POSITION für die automatische Topologieverwaltung angewiesen ist. Zusätzlich müssen alle beteiligten Tabellen die InnoDB-Engine mit Primärschlüssel verwenden, da Group Replication für die Konflikterkennung auf zeilenbasierte Zertifizierung angewiesen ist, die ohne Primärschlüssel nicht zuverlässig funktioniert.

Weitere Pflichtvoraussetzungen sind ein eindeutiger server_id je Knoten, aktiviertes binlog mit Row-Format sowie ein korrekt gesetzter report_host, damit sich Knoten im Netzwerk gegenseitig unter der richtigen Adresse erreichen. Die MySQL Shell bietet mit dba.checkInstanceConfiguration() ein eigenes Diagnosewerkzeug, das genau diese Voraussetzungen vor dem eigentlichen Cluster-Aufbau prüft und bei Bedarf über dba.configureInstance() automatisch nachrüstet.

# Instanz auf InnoDB-Cluster-Tauglichkeit pruefen und ggf. automatisch konfigurieren
mysqlsh -- dba checkInstanceConfiguration root@db1.internal:3306
mysqlsh -- dba configureInstance root@db1.internal:3306 --restart=true

4. Cluster aufbauen mit der MySQL Shell AdminAPI

Der eigentliche Aufbau erfolgt interaktiv oder skriptgesteuert über die JavaScript- oder Python-Konsole der MySQL Shell. dba.createCluster() initialisiert die erste Instanz als Seed-Knoten, legt das Metadata-Schema an und bootstrapt Group Replication mit automatisch berechneten Variablen. Jede weitere Instanz wird über cluster.addInstance() hinzugefügt, wobei die AdminAPI automatisch entscheidet, ob ein inkrementeller Datenabgleich per Klon-Plugin oder eine vollständige Recovery notwendig ist.

Diese Recovery-Entscheidung ist ein praktischer Vorteil gegenüber manuellem Setup: Statt manuell ein Backup einzuspielen und die Position abzugleichen, übernimmt der Clone-Plugin-Mechanismus einen konsistenten Datentransfer im Hintergrund, während die AdminAPI den Fortschritt überwacht und die Instanz erst dann als aktives Mitglied markiert, wenn der Datenbestand vollständig synchronisiert ist.

// In der MySQL Shell (mysqlsh --js)
shell.connect('root@db1.internal:3306');
var cluster = dba.createCluster('produktionCluster');

cluster.addInstance('root@db2.internal:3306', {recoveryMethod: 'clone'});
cluster.addInstance('root@db3.internal:3306', {recoveryMethod: 'clone'});

5. MySQL Router: automatische Portauswahl und Bootstrap

MySQL Router wird über den Befehl bootstrap gegen eine beliebige Cluster-Instanz initialisiert und liest dabei die Topologie automatisch aus dem Metadata-Schema aus, ganz ohne manuelle Angabe aller Knoten. Standardmäßig richtet der Bootstrap-Vorgang zwei Ports ein: Port 6446 für Schreib- und Lesezugriffe, die immer an den aktuellen Primary weitergeleitet werden, und Port 6447 für reine Lesezugriffe, die per Round-Robin auf die verfügbaren Sekundärknoten verteilt werden.

Für Anwendungen bedeutet das, dass sich Connection-Strings nach der Umstellung auf InnoDB Cluster nicht mehr an konkrete Datenbankserver, sondern ausschließlich an den Router richten, üblicherweise mehrfach installiert direkt neben der Anwendung, um eine zusätzliche Netzwerk-Hop-Latenz zu vermeiden und den Router selbst nicht zum Single Point of Failure zu machen.

mysqlrouter --bootstrap root@db1.internal:3306 --user=mysqlrouter --force
mysqlrouter --config /etc/mysqlrouter/mysqlrouter.conf &

# Anwendung verbindet sich fortan ausschliesslich mit dem Router:
# Schreib-/Lesezugriff:  db-app-host:6446
# Reine Lesezugriffe:    db-app-host:6447

6. Failover-Verhalten und die Rolle des Routers bei Primary-Wechsel

Fällt der aktuelle Primary aus, wählt Group Replication über ein internes Konsensverfahren automatisch einen neuen Primary aus den verbleibenden Online-Mitgliedern, üblicherweise innerhalb weniger Sekunden. Der Router erkennt diesen Wechsel, weil er kontinuierlich das Metadata-Schema aller Cluster-Knoten abfragt, und leitet neue Verbindungen auf Port 6446 automatisch an den neuen Primary weiter, ohne dass die Anwendung selbst etwas vom Wechsel merkt außer einer kurzen Verbindungsunterbrechung.

Bereits bestehende, offene Verbindungen zum alten Primary werden dabei nicht automatisch migriert, sie brechen ab und müssen von der Anwendung neu aufgebaut werden. Aus diesem Grund sollte Anwendungscode in jedem Fall über eine robuste Connection-Retry-Logik verfügen, unabhängig davon, ob InnoDB Cluster oder ein anderer HA-Mechanismus im Einsatz ist.

7. Cluster-Status überwachen: status() und describe()

Die AdminAPI stellt mit cluster.status() eine kompakte Momentaufnahme des aktuellen Cluster-Zustands bereit, inklusive der Rolle jedes Knotens, seines Group-Replication-Status und etwaiger Recovery-Vorgänge. cluster.describe() ergänzt dies um die reine Topologie-Struktur, unabhängig vom aktuellen operativen Status, was sich gut für automatisierte Konsistenzprüfungen in Monitoring-Skripten eignet.

Für tiefergehende Diagnosen bleibt der direkte Blick in performance_schema.replication_group_members sinnvoll, da die AdminAPI-Befehle intern auf dieselben Tabellen zugreifen, aber teilweise aggregieren. Wer eine eigene Monitoring-Pipeline aufbaut, sollte beide Quellen kombinieren: die AdminAPI für lesbare Statusberichte im Betrieb, die Performance-Schema-Tabellen für granulare Metriken im Zeitverlauf.

var cluster = dba.getCluster();
cluster.status();
cluster.describe();

8. Skalierung: addInstance, removeInstance und Rejoin nach Ausfall

Neue Knoten lassen sich jederzeit über cluster.addInstance() hinzufügen, ohne den laufenden Betrieb zu unterbrechen, während cluster.removeInstance() einen Knoten sauber aus Group Replication und Metadata-Schema entfernt. Fällt ein Knoten temporär aus, etwa durch einen Netzwerkpartition-Fehler, und kommt später zurück, erkennt die AdminAPI dies und bietet über cluster.rejoinInstance() einen gezielten Wiederanschluss ohne vollständige Neusynchronisation an, sofern der Rückstand klein genug ist.

Bei größerem Rückstand entscheidet die AdminAPI automatisch für eine vollständige Klon-basierte Neusynchronisation statt eines inkrementellen Rejoins, was in der Praxis Betriebszeit kostet, aber Dateninkonsistenzen zuverlässig ausschließt. Dieses automatische Abwägen zwischen inkrementellem Rejoin und vollständigem Neuaufbau ist einer der Bereiche, in denen die AdminAPI operative Entscheidungen trifft, die bei manuellem Group-Replication-Betrieb vollständig dem DBA-Team überlassen blieben.

9. Grenzen von InnoDB Cluster und wann der Ansatz nicht passt

InnoDB Cluster ist primär für Umgebungen mit niedriger Netzwerklatenz zwischen den Knoten konzipiert, da Group Replication für jede Transaktion einen Zertifizierungs-Roundtrip über alle Mitglieder benötigt. Über Standortgrenzen mit spürbarer WAN-Latenz hinweg leidet der Schreibdurchsatz spürbar, weshalb reine Multi-Region-Setups eher auf asynchrone Read Replicas als zusätzliche Ebene setzen sollten, statt das gesamte Cluster über mehrere Regionen zu spannen.

Im Multi-Primary-Modus, bei dem mehrere Knoten gleichzeitig Schreibzugriffe akzeptieren, steigt zudem das Risiko von Zertifizierungskonflikten bei gleichzeitigen Schreibzugriffen auf dieselbe Zeile, was Anwendungscode mit entsprechender Retry-Logik voraussetzt. Für Teams, die bereits ProxySQL oder eine eigene Orchestrierungslösung um ein manuelles Group-Replication-Setup gebaut haben, lohnt sich der Umstieg auf InnoDB Cluster oft nur, wenn die bestehende Lösung erkennbaren Wartungsaufwand verursacht, den die integrierte AdminAPI tatsächlich reduziert.

10. Zusammenfassung

11. FAQ: InnoDB Cluster: Das Wichtigste auf einen Blick