MySQL-Replikation nach einem VPN-Abbruch: zuerst beide Stufen lesen

Die Replikationsüberwachung wird rot, wenn die VPN-Verbindung abbricht, und der Instinkt ist, eine Position zurückzusetzen. Genau dieser Instinkt macht aus einer Netzunterbrechung ein Datenproblem. Ein abgebrochener Pfad sagt nichts darüber, was das Replikat empfangen oder angewendet hat, und das sind zwei Stufen mit zwei Zuständen. Lesen Sie beide getrennt, bevor Sie etwas ändern.

Zwei Stufen, zwei getrennte Antworten

Ein herkömmliches asynchrones Replikat erledigt zwei Aufgaben. Der Empfänger verbindet sich mit der Quelle, zieht Ereignisse und schreibt sie lokal in das Relay-Log. Der Applier liest dieses Relay-Log und führt die Ereignisse auf dem Replikat aus. Bricht der Pfad ab, stoppt der Empfänger sofort, während der Applier den Rückstand weiter abarbeitet, der bereits auf der Platte liegt. Ein Ausfall erzeugt daher zwei verschiedene Fragen: Ist die Verbindung zurück, und wurde die aufgelaufene Arbeit angewendet? Behandelt man beides als eine Frage, mittelt man zwei Zustände zu einer irreführenden Antwort.

Dass sich der Empfänger erholt, sagt Ihnen, dass der Pfad steht. Es sagt nichts darüber, wie weit der Applier zurückliegt oder ob er während der Trennung auf einen Fehler gestoßen ist.

Lesen Sie den Kanal mit der richtigen Anweisung

Unter MySQL 8.4 liefert SHOW REPLICA STATUS eine Zeile pro konfiguriertem Kanal, lesen Sie also die Zeile des Kanals, den Sie meinen, statt der ersten in der Liste. Replica_IO_Running unterscheidet einen verbundenen Empfänger von einem, der sich verbindet oder gestoppt ist, und Replica_SQL_Running beschreibt den Applier. Lesen Sie die Fehlerspalten daneben, denn ein Empfänger, der sich neu verbindet und sofort scheitert, hinterlässt eine Meldung, die kein Statusflag zeigt. Ältere Versionen verwenden andere Spaltennamen, übersetzen Sie ein altes Rezept also nicht, indem Sie nur Befehle umbenennen.

Prüfen Sie auch die Identität der Quelle und alle konfigurierten Filter. Ein Replikat, das auf die falsche Quelle zeigt oder enger gefiltert ist als gedacht, meldet Gesundheit, während es etwas anderes repliziert als erwartet.

Warum eine Null beim Rückstand lügen kann

Der Rückstandswert vergleicht den Zeitstempel des zuletzt angewendeten Ereignisses mit der aktuellen Zeit. War der Empfänger eine Stunde gestoppt, kann der Applier den Rückstand abarbeiten und das Ende des Empfangenen erreichen, worauf die Zahl auf null fällt, obwohl das Replikat eine Stunde hinter der Quelle liegt. Die Metrik misst die Warteschlange des Appliers, nicht die Aktualität des Replikats.

Vergleichen Sie stattdessen ausgeführte Transaktionen mit dem, was die Quelle verfügbar hat. Dieser Vergleich übersteht einen stockenden Empfänger.

Die Aufbewahrung bestimmt das echte Wiederherstellungsfenster

Aufholen setzt voraus, dass die Quelle die Transaktionen noch vorhält, die das Replikat braucht. Sind sie gelöscht, kann das Replikat sie nicht mehr holen, und kein noch so häufiges Neuverbinden ändert das.

Mit GTID-Autopositionierung ist der Fehler eindeutig: Das Replikat verlangt Verlauf, den die Quelle nicht mehr vorhält, und verweigert die Fortsetzung. Die Optionen sind dann, die fehlenden Ereignisse von einer Quelle zu holen, die sie noch hat, oder aus einer Sicherung neu aufzubauen und sie aufholen zu lassen. Die Lücke zu überspringen ist kein Aufholen, und es bleibt ein Replikat zurück, dessen Daten stillschweigend unvollständig sind. Planen Sie das Fenster, indem Sie die erwartete Ausfalldauer mit der Binärlog-Aufbewahrung auf der Quelle und der Änderungsrate vergleichen, denn diese drei Zahlen entscheiden, ob ein Ausfall überhaupt wiederherstellbar ist.

Prüfen Sie das Aufholen, nicht die Farbe einer Anzeige

Stellen Sie den Pfad wieder her, einschließlich Namensauflösung und Transportsicherheit, und beobachten Sie dann, ob sich der bestehende Kanal nach seiner eigenen Richtlinie neu verbindet. Geben Sie ihm ein definiertes Intervall, bevor Sie eingreifen, und halten Sie Empfangs- und Anwendungsfortschritt an beiden Enden dieses Intervalls fest. Ein Kanal, der neu startet, und ein Kanal, der aktuell ist, sind verschiedene Befunde.

Bestätigen Sie, dass der Applier die aktuelle Position der Quelle erreicht hat und nicht nur das Ende des alten Rückstands. Prüfen Sie, ob im Applier kein Fehler wartet, denn ein fehlgeschlagenes Ereignis stoppt den Fortschritt, während der Empfänger weiter Verbundenheit meldet. Halten Sie dann die Belege fest: Kanalname, beide Stufenzustände, die ausgeführte Position und die Uhrzeit. Eine grüne Anzeige ist eine Behauptung; die Position ist eine Tatsache.