MySQL-Replikation: täglicher Betrieb und Störungsszenarien (8.0 / 8.4)

Runbook für den täglichen Betrieb und die Störungsbehebung einer bestehenden Source-+-Replica-Topologie (async / semi-sync, GTID oder Binlog-Position): Zustands- und Lag-Prüfung, geplanter Switchover, Failover, Wiedereingliedern der alten Source, Neuaufbau einer Replica (clone / XtraBackup / mysqldump), Errant GTIDs, Fehler 1062/1032, Datenwiederherstellung aus einer verzögerten Replica, Umhängen einer Replica und Binlog-Bereinigung. Jedes Szenario folgt dem Ablauf Diagnose → Sicherheitsnetz → Durchführung → Prüfung → Nacharbeit. Dies ist keine Installationsanleitung: Um die Replikation erstmals einzurichten, öffne den Guide «MySQL GTID-Replikation», für InnoDB Cluster (Group Replication) den Guide «InnoDB Cluster Betrieb».

Topologie: 1 Source + 1..5 Replicas (async / semi-sync)

Szenarien

• Status- und Lag-Prüfung (ist die Replikation gesund?) — Nur lesend: IO-/SQL-Threads, letzte Fehler, tatsächlicher Lag, Semi-Sync-Status und Errant-GTID-Prüfung; nichts wird verändert, keine Downtime. Wenn du nicht sicher bist, was zu tun ist, beginne hier: Der letzte Schritt verweist anhand der Ausgabe auf das passende Szenario.
• Geplanter Switchover (Source-Rolle an eine Replica übergeben) — Source und Replicas sind gesund; du übergibst die Source-Rolle geplant an eine Replica, etwa für Wartung, Hardwaretausch oder ein Upgrade. Schreibzugriffe stehen einige Minuten still, es gehen keine Daten verloren; der Rückweg ist dasselbe Szenario in umgekehrter Richtung.
• Source verloren: Failover auf die am weitesten fortgeschrittene Replica — Die Source ist abgestürzt oder nicht erreichbar und kommt so bald nicht zurück (IO-Thread auf den Replicas Connecting, 2003/2013). Die am weitesten fortgeschrittene Replica wird zur neuen Source, die anderen verbinden sich mit ihr. Schreibzugriffe sind unterbrochen, bis die neue Source freigegeben ist; bei asynchroner Replikation können die letzten Transaktionen der Source verloren gehen.
• Alte Source nach dem Failover als Replica wieder eingliedern — Ein Failover wurde durchgeführt, der alte Source-Server ist wieder da. Er wird zuerst für Schreibzugriffe gesperrt, seine Binlogs werden kopiert und auf Errant Transactions geprüft; ist er sauber, wird er direkt zur Replica, andernfalls wird er von der neuen Source neu aufgebaut. Keine Downtime auf der neuen Source.
• Replica von Grund auf neu aufbauen (clone / XtraBackup / mysqldump) — Die Binlogs, die die Replica braucht, wurden auf der Source gelöscht (1236), ihre Daten sind von der Source abgewichen, 1062/1032 tauchen immer wieder auf oder die Platte der Replica ist verloren. Sämtliche Daten der Replica werden durch eine Kopie der Source ersetzt; die Source bleibt online, die Ziel-Replica ist in dieser Zeit nicht nutzbar.
• Errant GTID: Die Replica hat Transaktionen, die es auf der Source nicht gibt — Es gibt Transaktionen, die direkt auf die Replica geschrieben wurden (während super_read_only aus war) oder von einer alten Source übrig sind; bei einem Failover verbreiten sie sich auf die anderen Replicas oder stoppen die Replikation mit 1236. Lösung: leere Transaktion, Anwenden auf der Source oder Neuaufbau. Keine Downtime.
• Replikation gestoppt: 1062 Duplicate entry / 1032 Can't find record — Der SQL-Thread ist mit einem Datenfehler stehen geblieben (Replica_SQL_Running: No, Last_SQL_Errno 1062/1032/1146/1677…). Zuerst wird die Zeile in den Zustand auf der Source gebracht; geht das nicht, wird als letztes Mittel eine einzelne Transaktion übersprungen. Betroffen ist nur diese Replica: Sie fällt zurück, und Anwendungen, die von ihr lesen, sehen veraltete Daten.
• Verzögerte Replica (SOURCE_DELAY): einrichten oder gelöschte Daten zurückholen — Du willst eine Replica bewusst N Sekunden hinter der Source halten (Verzögerung setzen / entfernen) oder versehentlich gelöschte/geänderte Daten (DROP, DELETE/UPDATE ohne WHERE) aus der verzögerten Replica zurückholen, bevor die Änderung dort angewendet wird. Die Source bleibt online.
• Replica an eine andere Source umhängen (Kette / Neuverbindung) — Du willst eine Replica unter eine andere Replica hängen (Kette / Zwischen-Replica) oder wieder direkt an die Source anbinden; es werden keine Daten kopiert, nur die Verbindung ändert sich. Die umgehängte Replica steht einige Sekunden still.
• Binlog-Bereinigung und Aufbewahrungsdauer (Platte läuft voll) — Binlogs füllen die Platte oder du willst die Aufbewahrungsdauer einstellen; bereinigt wird, ohne Dateien zu löschen, die Replicas und PITR noch brauchen. Keine Downtime.

Vor dem Start

• Auf allen Servern MySQL …… (ab 8.0.26)… in derselben Minor-Version…, gtid_mode = ON und enforce_gtid_consistency = ON…, Binlog aktiv…; der Betriebssystem-root kann sich mit mysql ohne Passwort verbinden (auth_socket oder ~/.mylogin.cnf). Die Topologie wurde mit dem Replikations-Installations-Guide oder gleichwertig aufgebaut.
• Es ist geprüft, dass die Rollen den Eingaben entsprechen: … (…)… ist die verlorene alte Source… ist die aktuelle Source (read_only = 0, keine Replica-Konfiguration)…, die Server in der Liste sind Replicas.… Beim Failover zur Source geworden: … (…).…
• Das Passwort des Kontos … ist bekannt. Das Konto existiert für die IP jedes Servers ('…'@'<ip>', REQUIRE SSL); die Schritte lesen damit Werte wie das GTID-Set auf den anderen Servern und verwenden es beim Rollenwechsel für die Replikationsverbindung. Das Passwort enthält kein ', " und \.
• Die Server erreichen sich gegenseitig über Port ….
• Auf allen Servern sind beide Semi-Sync-Plugins geladen und ACTIVE: rpl_semi_sync_source (semisync_source.so) und rpl_semi_sync_replica (semisync_replica.so); beim Rollenwechsel werden auf jedem Server beide Seiten ein- bzw. ausgeschaltet. Sind die alten rpl_semi_sync_master / rpl_semi_sync_slave (vor 8.0.26, in 8.4 veraltet) geladen, gibt es die in den Schritten verwendeten Variablen rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled nicht: Entferne zuerst das alte Plugin mit UNINSTALL PLUGIN und installiere das neue (beide können nicht gleichzeitig auf einem Server geladen sein; INSTALL PLUGIN wird auf einem schreibgeschützten Server abgelehnt, daher super_read_only vorübergehend ausschalten).
• Auf der Replica, die neue Source / Zwischenserver wird, gilt log_bin = ON und log_replica_updates = ON (Standard in 8.x); andernfalls enthält ihr Binlog die von der Source kommenden Transaktionen nicht, und die anderen Replicas können sich nicht mit ihr verbinden.
• Für die Dateiübertragung besteht zwischen den beteiligten Servern root-SSH-Zugang (per Schlüssel)…: … → ……. Andernfalls übertrage die Dateien mit dem freigegebenen Verfahren deiner Organisation; die Schritte zeigen die Dateipfade.
• Auf Donor (…) und Ziel (…) ist Percona XtraBackup in derselben Hauptversion wie MySQL installiert; auf dem Donor existiert das Backup-Konto bkpuser (auth_socket) — die ersten beiden Phasen des XtraBackup-Guides.
• Freigabe für die Änderung und ein Kommunikationskanal liegen vor (Anwendungsteam, Wartungsfenster). Für einen Rollenwechsel ist geklärt, wer den Schreibendpunkt der Anwendung (VIP, DNS, ProxySQL / HAProxy / Router) wie umstellt.

Phasen der Anleitung

• Status: Source, Replicas und Lag (nur lesend) — Rolle, Binlog-Position und verbundene Replicas der Source anzeigen · Thread-Status, Fehler und Lag der Replicas anzeigen · Tatsächlichen Lag und Apply-Warteschlange aus performance_schema messen · Errant-GTID-Prüfung (hat die Replica Transaktionen, die es auf der Source nicht gibt?) · Ergebnis auswerten und das passende Szenario wählen
• 1. Diagnose: bereit für den Switchover? — Source und verbundene Replicas prüfen · Eignung der Kandidaten-Replica prüfen · Prüfen, ob alle Replicas gesund sind
• 2. Sicherheitsnetz — Aktuellen Zustand auf allen Servern sichern
• 3. Durchführung: Rolle übergeben — Schreibzugriffe der Anwendung stoppen · Source für Schreibzugriffe sperren und letzte Position ermitteln · Warten, bis die Replicas zur Source aufgeholt haben · Kandidaten zur Source machen (Promote) · Alte Source zur Replica der neuen Source machen · Die anderen Replicas mit der neuen Source verbinden (…) …
• 4. Prüfung — Testschreibvorgang auf der neuen Source · Replikation und Testzeile auf allen Servern prüfen
• 5. Nacharbeit — Testdatenbank löschen und Betrieb anpassen
• 1. Diagnose: Ist die Source wirklich verloren, welche Replica ist am weitesten? — Source ein letztes Mal zu erreichen versuchen (von der Kandidaten-Replica) · Alte Source isolieren (Fencing) · Auf jeder Replica warten, bis die Transaktionen im Relay Log angewendet sind · Am weitesten fortgeschrittene Replica ermitteln · Am weitesten fortgeschrittene Replica ermitteln (positionsbasiert)
• 2. Sicherheitsnetz — Aktuellen Zustand auf den Replicas sichern
• 3. Durchführung: Failover — Kandidaten zur Source machen (Promote) · Die anderen Replicas mit der neuen Source verbinden (…) · Schreibzugriffe auf der neuen Source freigeben · Anwendung auf die neue Source umleiten
• 4. Prüfung — Testschreibvorgang auf der neuen Source · Replikation und Testzeile auf den Replicas prüfen
• 5. Nacharbeit — Verlorene Transaktionen, Backup und alte Source einplanen
• 1. Diagnose: Ist die alte Source sauber? — Status der alten Source anzeigen · Errant Transactions finden (Vergleich mit der neuen Source) · Entscheidung zur Wiedereingliederung bei positionsbasierter Replikation
• 2. Sicherheitsnetz — Alte Source sofort für Schreibzugriffe sperren und Zustand sichern · Errant Transactions in eine separate Datei extrahieren
• 3. Durchführung: als Replica anbinden — Alte Source mit der neuen Source verbinden
• 4. Prüfung — Prüfen, dass die alte Source als Replica läuft
• 5. Nacharbeit — Topologie und Zukunft der alten Source planen
• 1. Diagnose: Wie lautet das Errant-Set? — Errant-GTID-Set berechnen
• 2. Sicherheitsnetz: Inhalt der Errant Transactions sichern — Errant Transactions aus dem Binlog dekodieren und sichern
• 3. Durchführung: leere Transaktionen auf der Source einschleusen — Errant GTIDs auf der Source als leere Transaktionen ausführen
• 3. Durchführung: Errant Transactions auf der Source anwenden — Errant Transactions in eine Datei extrahieren und auf die Source kopieren · Transaktionen auf der Source anwenden
• 4. Prüfung — Prüfen, dass kein Errant-Set übrig ist
• 5. Nacharbeit: Wiederholung verhindern — Ursache finden und Replicas schützen
• 1. Diagnose: welche Transaktion, welche Zeile? — Fehler und fehlgeschlagene Transaktion anzeigen · Zeilen der fehlgeschlagenen Transaktion aus dem Relay Log dekodieren · Zeile auf Source und Replica vergleichen
• 2. Sicherheitsnetz — Replica-Status und aktuellen Zustand der Tabelle sichern
• 3. Durchführung: Zeile auf der Replica korrigieren — Korrektur-SQL vorbereiten · Korrektur ohne Binlog-Eintrag anwenden und Replikation starten
• 3. Durchführung: fehlgeschlagene Transaktion überspringen (letztes Mittel) — Nur die fehlgeschlagene Transaktion überspringen
• 4. Prüfung — Zeile und Prüfsumme der Tabelle auf beiden Seiten vergleichen
• 5. Nacharbeit — Ursache finden
• 1. Diagnose — Aktuelle Verzögerungseinstellung der Replica anzeigen
• 2. Sicherheitsnetz — Replica-Status sichern