MySQL InnoDB Cluster: täglicher Betrieb und Störungsszenarien (MySQL Shell 8.4)

Keine Installation: ein szenariobasiertes Runbook für den täglichen Betrieb und die Störungsbehebung eines bereits laufenden InnoDB Clusters (Group Replication + MySQL Router, eingerichtet mit der MySQL Shell AdminAPI). Wähle eine Szenariokarte: Health Check, Mitglied hinzufügen (Clone / Incremental) und entfernen (auch mit force), ausgefallenes Mitglied wieder aufnehmen, Neustart nach Ausfall des gesamten Clusters (rebootClusterFromCompleteOutage), forceQuorumUsingPartitionOf bei Verlust der Mehrheit, geplanter Primary-Wechsel, Router hinzufügen / neu bootstrappen, Cluster-Optionen (consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction) und rescan() für die Metadaten. Jedes Szenario folgt dem Schema Diagnose → Sicherheitsnetz → Durchführung → Prüfung → Nacharbeit. Richtest du den Cluster zum ersten Mal ein, öffne den Installations-Guide für InnoDB Cluster; für klassische Source-Replica-Replikation den Guide zum Replikationsbetrieb, für den Umstieg von 8.0 auf 8.4 den Upgrade-Guide.

Topologie: 3–9 MySQL-Nodes (Single-Primary) + MySQL Router

Szenarien

• Cluster-Status und Health Check (ist alles in Ordnung?) — Nur lesend: cluster.status({extended: 1}), Rolle/Zustand/Version der Mitglieder, Applier-Queues, Router-Liste und Error Log; es wird nichts geändert, keine Downtime. Fang hier an, wenn du unsicher bist oder ein Alarm kam; der letzte Schritt verweist dich auf das passende Szenario.
• Neues Mitglied hinzufügen (addInstance: Clone / Incremental) — Du willst dem Cluster einen neuen MySQL-Node hinzufügen, die Ausfalltoleranz erhöhen (3 → 5) oder einen entfernten Node zurückholen. Der Cluster bleibt für Schreibzugriffe offen; während des Clones entsteht auf dem Donor Platten-/Netzwerklast, der neue Node startet neu.
• Mitglied entfernen (removeInstance, bei Bedarf force) — Du willst einen Node dauerhaft aus dem Cluster entfernen (Hardware-Rückgabe, Verkleinerung) oder ein Node ist verloren und muss aus den Metadaten gelöscht werden (force). Beim Entfernen eines Secondary gibt es keine Downtime; wird der Primary entfernt, sind Schreibzugriffe einige Sekunden unterbrochen.
• Ausgefallenes Mitglied wieder aufnehmen (MISSING / ERROR / OFFLINE) — Ein Mitglied wurde neu gestartet, hatte eine Netzwerkunterbrechung oder wurde aus der Gruppe ausgeschlossen (expelled); die Mehrheit läuft und die Anwendung kann schreiben. Mit rejoinInstance holt das Mitglied den Rückstand auf und kehrt zurück; im Cluster gibt es keine Downtime.
• Gesamter Cluster ausgefallen: neu starten (rebootClusterFromCompleteOutage) — Wegen eines Strom-, Rechenzentrums- oder Hypervisor-Ausfalls o. Ä. sind alle Nodes ausgefallen und wieder hochgefahren; Group Replication läuft auf keinem Mitglied, die Anwendung kann nicht schreiben (die Downtime dauert an). Der Cluster wird vom aktuellsten Mitglied aus neu gestartet.
• Verlust der Mehrheit (NO_QUORUM): Quorum mit den verbliebenen Mitgliedern erzwingen — Die meisten Mitglieder sind gleichzeitig verloren gegangen (z. B. 2 von 3), die übrigen haben mit NO_QUORUM die Schreibzugriffe gestoppt (Schreibvorgänge hängen). Bist du sicher, dass die verlorenen Mitglieder wirklich gestoppt sind, wird der Cluster mit der verbliebenen Partition wieder in Betrieb genommen. Falsche Anwendung erzeugt Split-Brain; der Verlust eines einzelnen Mitglieds (Mehrheit steht) ist nicht dieses Szenario.
• Geplanter Primary-Wechsel (setPrimaryInstance) — Du willst die Primary-Rolle für Wartung (OS-Patch, Hardware), Lastverteilung oder eine DR-Probe geplant an einen bestimmten Secondary übergeben. Schreibzugriffe warten einige Sekunden, offene Transaktionen werden abgeschlossen; der Router leitet von selbst auf den neuen Primary um.
• Router hinzufügen oder neu bootstrappen — Du willst auf einem neuen Anwendungsserver einen Router installieren, den Router neu bootstrappen (Versions-Upgrade, neu aufgebauter Cluster, Warnung routerErrors) oder alte Router-Einträge bereinigen. Beim erneuten Bootstrap brechen die Anwendungsverbindungen über diesen Router kurz ab.
• Cluster-Optionen ändern (consistency, expelTimeout, memberWeight…) — Du willst die Failover-Konsistenz, die Zeit bis zum Ausschluss eines Mitglieds bei Netzwerkschwankungen, die Failover-Priorität, den automatischen Wiederbeitritt oder das Verhalten eines Mitglieds im Fehlerfall einstellen. Die Änderung erfolgt im laufenden Cluster, ohne Neustart; consistency wirkt in neuen Sitzungen.
• Metadaten mit der tatsächlichen Gruppe abgleichen (rescan) — cluster.status() nennt ein Mitglied, das nicht in den Metadaten steht, oder einen alten Eintrag, der nicht mehr in der Gruppe ist (manuelles START GROUP_REPLICATION, altes Mitglied nicht gelöscht, Server neu aufgesetzt). Keine Downtime; nur die Metadaten werden aktualisiert.

Vor dem Start

• Auf den betroffenen Nodes sind MySQL Shell … und MySQL … installiert; der Cluster wurde mit dem Installations-Guide für InnoDB Cluster oder gleichwertig mit der AdminAPI eingerichtet (Metadaten vorhanden). Der Betriebssystem-root kann sich lokal mit mysql ohne Passwort verbinden. Den Cluster-Namen für das Formular liefert dba.getCluster().getName(), die Mitgliederadressen die ip:port-Zeilen in der Topologie von cluster.status().
• Das Passwort des Kontos … ist bekannt (auf jedem Node gleich). MySQL Shell fragt das Passwort bei jeder Verbindung ab; mit --save-passwords=never wird es nicht gespeichert.
• Die Nodes erreichen sich gegenseitig über die MySQL-Ports (……:……, ……) und die Kommunikationsports von Group Replication.
• Auf dem neuen Node ist MySQL … im selben Minor-Release wie die Cluster-Mitglieder installiert (Voraussetzung für Clone), GTID ist an, server_id unterscheidet sich von den anderen Nodes und die Group-Replication-Einstellungen aus dem Installations-Guide stehen in der my.cnf; Firewall-/SELinux-Ports sind offen.
• Der Router-Server erreicht die Nodes über den MySQL-Port… und kann repo.mysql.com erreichen….
• Freigabe der Änderung, Wartungsfenster (falls nötig) und Abstimmung mit dem Anwendungsteam liegen vor.

Phasen der Anleitung

• Status: Cluster, Mitglieder und Router (nur lesend) — Detaillierten Cluster-Status abrufen und speichern · Mitglieder und Queues per SQL prüfen · Fehlereinträge von Group Replication durchsuchen · RW/RO-Routing über den Router prüfen · Ergebnis auswerten und passendes Szenario wählen
• 1. Diagnose: Sind neuer Node und Cluster bereit? — Version und Identität des neuen Nodes prüfen · Cluster-Status und Versionen der Mitglieder prüfen
• 2. Sicherheitsnetz — Aktuelle Topologie speichern
• 3. Durchführung: Mitglied hinzufügen — Neuen Node konfigurieren und Administratorkonto anlegen · Eignung des neuen Nodes aus Sicht des Clusters prüfen · Node zum Cluster hinzufügen (…)
• 4. Prüfung — Prüfen, ob das neue Mitglied ONLINE ist
• 5. Nacharbeit — Router, Monitoring und Inventar aktualisieren
• 1. Diagnose: Ist das Entfernen des Mitglieds sicher? — Zustand des Zielmitglieds und verbleibende Toleranz anzeigen
• 2. Sicherheitsnetz — Aktuelle Topologie speichern
• 3. Durchführung: Mitglied entfernen — Mitglied aus dem Cluster entfernen… (force)…
• Wenn ein mit force entfernter Node zurückkommt — Group Replication auf dem zurückgekehrten Node stoppen und bereinigen
• 4. Prüfung — Verbleibende Mitglieder prüfen
• 5. Nacharbeit — Ungerade Zahl, Router und Monitoring
• 1. Diagnose: Warum ist das Mitglied ausgefallen, kann es wieder beitreten? — Zustand des Zielmitglieds aus Sicht des Clusters · Zustand von MySQL und Group Replication auf dem Ziel-Node anzeigen · Prüfung auf Errant Transactions (auf dem Ziel, aber nicht im Cluster)
• 2. Sicherheitsnetz — Aktuellen Zustand speichern
• 3. Durchführung: Mitglied wieder aufnehmen — Mitglied mit rejoinInstance wieder aufnehmen
• 4. Prüfung — Prüfen, ob das Mitglied ONLINE ist
• 5. Nacharbeit — Ursache und automatischer Wiederbeitritt
• 1. Diagnose: Ist wirklich der gesamte Cluster down, welches Mitglied ist am aktuellsten? — MySQL auf jedem Node starten und Zustand von Group Replication anzeigen · Shell nach dem aktuellsten Mitglied fragen (dryRun)
• 2. Sicherheitsnetz — GTID-Set aller Nodes speichern
• 3. Durchführung: Cluster vom aktuellsten Mitglied starten — Cluster neu starten
• 4. Prüfung — Prüfen, ob alle Mitglieder ONLINE sind
• 5. Nacharbeit — Router, Anwendung und Ursache
• 1. Diagnose: Ist das Quorum wirklich verloren? — Cluster-Status vom verbliebenen Node anzeigen
• 2. Sicherheitsnetz: verlorene Mitglieder isolieren — Sicherstellen, dass die verlorenen Nodes gestoppt sind (Fencing) · Zustand der verbliebenen Partition speichern
• 3. Durchführung: Quorum erzwingen — Quorum mit der verbliebenen Partition herstellen
• 4. Prüfung und Rückholen der verlorenen Mitglieder — Prüfen, ob Schreibzugriffe freigegeben sind · Verlorene Mitglieder wieder aufnehmen (…)
• 5. Nacharbeit — Topologie überprüfen
• 1. Diagnose: Ist das Ziel als Primary geeignet? — Zustand und Versionen der Mitglieder prüfen
• 2. Sicherheitsnetz — Aktuellen Zustand speichern
• 3. Durchführung: Primary wechseln — Primary-Rolle an … übergeben