Replica defekt / Resync nötig
Die Synchronisierung zwischen Replica/Standby und Primary ist unterbrochen. Bestimme, ob die Replikation gestoppt ist, wie weit sie zurückliegt und ob die Positions-/GTID-Kette gebrochen ist; wähle dann den richtigen Weg zwischen Überspringen eines Fehlers, Abwarten oder Neuaufbau (Reseed). Mit Split-Brain-Warnung.
Wie ist der Gesamtzustand der Replikation?
Lies zuerst den Replikationszustand: Laufen die Apply-Threads, wie groß ist der Verzug, gibt es einen Fehler? Verifiziere auch, dass nicht beide Knoten Schreibvorgänge annehmen (Split-Brain).
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- Replikation ist gestoppt / schlägt fehl
- Läuft, liegt aber weit zurück (großer Verzug)
- GTID/Position gebrochen, inkonsistent — neu aufbauen
- Beide Knoten schreiben als Primary (Verdacht auf Split-Brain)
Lässt sich der Fehler reparieren, oder ist ein Neuaufbau nötig?
Untersuche den Apply-Fehler. Manche Fehler (Duplicate Key, fehlende Zeile) lassen sich durch sicheres Überspringen eines einzelnen Ereignisses beheben; bei Dateninkonsistenz/Korruption ist der Neuaufbau der Replica aber der einzig richtige Weg.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- Ein/wenige Apply-Fehler (überspringbar)
- Nicht reparierbare Inkonsistenz / Korruption
Ist der Verzug vorübergehend oder dauerhaft?
Sieh dir den Verlauf des Verzugs über die Zeit an. Schließt er sich nach einer vorübergehenden Lastspitze (Aufholen), oder wächst er weiter, sodass die Replica den Primary nie einholt?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- Vorübergehende Lastspitze; Verzug schließt sich
- Wächst weiter; kann nicht aufholen
Lösung: Apply-Fehler vorsichtig überspringen
Ist die Replikation an einem einzelnen Apply-Fehler (z. B. Duplicate Key) gestoppt und bist du sicher, dass die Daten tatsächlich konsistent sind, kannst du dieses Ereignis überspringen und den Stream fortsetzen. Das ist ein letztes Mittel; blindes Überspringen erzeugt stillen Daten-Drift.
Lösung: Replica neu aufbauen (Reseed / Rebuild)
Ist die Positions-/GTID-Kette gebrochen, sind die Daten abgedriftet oder gibt es einen nicht reparierbaren Fehler, ist der einzig verlässliche Weg, die Replica aus einer frischen Kopie des Primary neu aufzubauen.
Ursache: vorübergehende Lastspitze (Verzug schließt sich)
Die Replikation ist gesund; der Verzug ist durch eine vorübergehende Schreibspitze auf dem Primary oder Netzwerkschwankungen entstanden, die Replica holt aber auf.
Ursache: Die Replica hält mit dem Primary nicht Schritt
Die Apply-Seite (Apply/Redo) kommt mit der Änderungsrate des Primary nicht mit; der Verzug wächst ständig. Meist liegt es an Single-Thread-Apply, langsamer Replica-Hardware oder einem Netzwerkengpass.
WARNUNG: Split-Brain (zwei Primaries) — Datenverlustrisiko
Nehmen beide Knoten in der Primary-Rolle Schreibvorgänge an, häufen sich auf beiden Seiten widersprüchliche Änderungen; das ist die gefährlichste Lage und kann zu Datenverlust führen. Vorrang hat, Schreibvorgänge auf einen einzigen Knoten zu beschränken.