Replikacja MySQL po zerwaniu VPN: najpierw przeczytaj oba etapy

Monitoring replikacji zmienia się na czerwony, gdy VPN pada, a odruch każe zresetować pozycję. Ten odruch jest sposobem, w jaki przerwa w sieci staje się problemem z danymi. Zerwana ścieżka nie mówi nic o tym, co replika odebrała lub zastosowała, a to dwa etapy o dwóch stanach. Przeczytaj je osobno, zanim cokolwiek zmienisz.

Dwa etapy, dwie osobne odpowiedzi

Zwykła replika asynchroniczna wykonuje dwa zadania. Odbiornik łączy się ze źródłem, pobiera zdarzenia i zapisuje je lokalnie w dzienniku przekazywania. Aplikator czyta ten dziennik i wykonuje zdarzenia na replice. Gdy ścieżka się zrywa, odbiornik zatrzymuje się natychmiast, a aplikator nadal przetwarza zaległości, które już są na dysku. Jeden incydent rodzi więc dwa różne pytania: czy połączenie wróciło i czy nagromadzona praca została zastosowana? Traktowanie ich jako jednego pytania uśrednia dwa stany w mylącą odpowiedź.

To, że odbiornik się podnosi, mówi ci, że ścieżka działa. Nie mówi nic o tym, jak bardzo aplikator jest z tyłu ani czy natrafił na błąd podczas rozłączenia.

Czytaj kanał właściwą instrukcją

W MySQL 8.4 SHOW REPLICA STATUS zwraca jeden wiersz na każdy skonfigurowany kanał, więc czytaj wiersz kanału, o którym myślisz, a nie pierwszy na liście. Replica_IO_Running odróżnia odbiornik połączony od tego, który się łączy lub jest zatrzymany, a Replica_SQL_Running opisuje aplikator. Czytaj obok kolumny błędów, bo odbiornik, który łączy się ponownie i od razu zawodzi, zostawia komunikat, którego nie pokaże żadna flaga stanu. Starsze wersje używają innych nazw kolumn, więc nie tłumacz starej recepty samym przemianowaniem poleceń.

Sprawdź także tożsamość źródła i skonfigurowane filtry. Replika wskazująca niewłaściwe źródło lub filtrowana węziej, niż myślisz, zgłasza zdrowie, replikując coś innego, niż oczekujesz.

Dlaczego zerowe opóźnienie może kłamać

Wartość opóźnienia porównuje znacznik czasu ostatniego zastosowanego zdarzenia z bieżącym czasem. Gdy odbiornik był zatrzymany przez godzinę, aplikator może przetworzyć zaległości i dotrzeć do końca tego, co odebrał, i wtedy liczba spada do zera, choć replika jest godzinę za źródłem. Metryka mierzy kolejkę aplikatora, a nie aktualność repliki.

Zamiast tego porównaj wykonane transakcje z tym, co źródło ma dostępne. To porównanie przeżywa zablokowany odbiornik.

Realne okno odzyskiwania wyznacza retencja

Dogonić można tylko wtedy, gdy źródło nadal przechowuje transakcje potrzebne replice. Gdy zostaną wyczyszczone, replika nie może ich pobrać i żadne ponowne połączenie tego nie zmieni.

Przy automatycznym pozycjonowaniu GTID awaria jest jawna: replika prosi o historię, której źródło już nie przechowuje, i odmawia kontynuacji. Opcje to pobranie brakujących zdarzeń ze źródła, które je jeszcze ma, albo odbudowa z kopii zapasowej i pozwolenie jej dogonić. Przeskoczenie luki nie jest dogonieniem i zostawia replikę, której dane są po cichu niekompletne. Zaplanuj okno, porównując przewidywany czas trwania awarii z retencją dziennika binarnego na źródle i tempem zmian, bo te trzy liczby decydują, czy awaria jest w ogóle odzyskiwalna.

Weryfikuj dogonienie, nie kolor wskaźnika

Przywróć ścieżkę, w tym rozwiązywanie nazw i bezpieczeństwo transportu, a potem obserwuj, czy istniejący kanał połączy się ponownie zgodnie z własną polityką. Daj mu zdefiniowany interwał, zanim interweniujesz, i zapisz postęp odbioru oraz stosowania na obu końcach tego interwału. Kanał, który się restartuje, i kanał, który jest aktualny, to różne ustalenia.

Potwierdź, że aplikator osiągnął bieżącą pozycję źródła, a nie tylko koniec starych zaległości. Sprawdź, czy w aplikatorze nie czeka błąd, bo jedno nieudane zdarzenie zatrzymuje postęp, podczas gdy odbiornik nadal zgłasza połączenie. Następnie zapisz dowody: nazwę kanału, stany obu etapów, wykonaną pozycję i czas. Zielony wskaźnik to twierdzenie; pozycja to fakt.