MySQL replikacija nutrūkus VPN: pirmiausia perskaitykite abu etapus

Replikacijos stebėjimas paraudonuoja, kai nukrenta VPN, ir instinktas yra atstatyti poziciją. Būtent šis instinktas tinklo sutrikimą paverčia duomenų problema. Nutrūkęs kelias nieko nesako apie tai, ką replika gavo ar pritaikė, o tai du etapai su dviem būsenomis. Perskaitykite juos atskirai, prieš ką nors keisdami.

Du etapai, du atskiri atsakymai

Įprasta asinchroninė replika atlieka du darbus. Gavėjas prisijungia prie šaltinio, ištraukia įvykius ir įrašo juos vietoje į perdavimo žurnalą. Taikytojas skaito šį žurnalą ir vykdo įvykius replikoje. Kai kelias nutrūksta, gavėjas sustoja iškart, o taikytojas toliau apdoroja diske jau esantį atsilikimą. Taigi vienas sutrikimas sukuria du skirtingus klausimus: ar ryšys grįžo, ir ar sukauptas darbas pritaikytas? Traktuojant juos kaip vieną klausimą, dvi būsenos suvidurkinamos į klaidinantį atsakymą.

Gavėjo atsistatymas pasako, kad kelias veikia. Jis nieko nesako apie tai, kiek taikytojas atsiliko, ar jis susidūrė su klaida būdamas atjungtas.

Skaitykite kanalą tinkamu teiginiu

MySQL 8.4 versijoje SHOW REPLICA STATUS grąžina po vieną eilutę kiekvienam sukonfigūruotam kanalui, todėl skaitykite norimo kanalo eilutę, o ne pirmąją sąraše. Replica_IO_Running atskiria prisijungusį gavėją nuo prisijungiančio ar sustabdyto, o Replica_SQL_Running apibūdina taikytoją. Skaitykite šalia esančius klaidų stulpelius, nes gavėjas, kuris vėl prisijungia ir iškart nepavyksta, palieka pranešimą, kurio neparodys jokia būsenos vėliavėlė. Senesnės versijos naudoja kitus stulpelių pavadinimus, todėl neverskite seno recepto vien pervadindami komandas.

Patikrinkite ir šaltinio tapatybę bei sukonfigūruotus filtrus. Replika, nukreipta į neteisingą šaltinį arba filtruojama siauriau, nei manote, praneša apie sveikatą, nors replikuoja ką kita, nei tikitės.

Kodėl nulinis vėlavimas gali meluoti

Vėlavimo reikšmė lygina paskutinio pritaikyto įvykio laiko žymą su dabartiniu laiku. Kai gavėjas buvo sustabdytas valandą, taikytojas gali apdoroti atsilikimą ir pasiekti gautojo pabaigą, ir tada skaičius nukrenta iki nulio, nors replika valanda atsilieka nuo šaltinio. Metrika matuoja taikytojo eilę, o ne replikos aktualumą.

Vietoj to palyginkite įvykdytas transakcijas su tuo, ką šaltinis turi. Toks palyginimas atlaiko sustojusį gavėją.

Tikrąjį atkūrimo langą nustato saugojimas

Kad pasivytų, šaltinis turi dar saugoti transakcijas, kurių replikai reikia. Joms išvalius, replika negali jų gauti, ir joks pakartotinis prisijungimas to nepakeis.

Su automatiniu GTID pozicionavimu gedimas yra aiškus: replika prašo istorijos, kurios šaltinis jau nebenaudoja, ir atsisako tęsti. Tada variantai yra gauti trūkstamus įvykius iš šaltinio, kuris juos dar turi, arba atstatyti iš atsarginės kopijos ir leisti jai pasivyti. Spragos praleidimas nėra pasivijimas, ir jis palieka repliką, kurios duomenys tyliai nepilni. Planuokite langą lygindami numatomą sutrikimo trukmę su dvejetainio žurnalo saugojimu šaltinyje ir pokyčių tempu, nes šie trys skaičiai nusprendžia, ar sutrikimą apskritai galima atkurti.

Tikrinkite pasivijimą, o ne indikatoriaus spalvą

Atkurkite kelią, įskaitant vardų skiriamąją gebą ir transporto saugumą, tada stebėkite, ar esamas kanalas vėl prisijungia pagal savo politiką. Duokite jam nustatytą intervalą prieš įsikišdami ir užfiksuokite priėmimo bei taikymo eigą abiejuose to intervalo galuose. Kanalas, kuris paleidžiamas iš naujo, ir kanalas, kuris yra aktualus, yra skirtingi radiniai.

Patvirtinkite, kad taikytojas pasiekė dabartinę šaltinio poziciją, o ne tik seno atsilikimo pabaigą. Patikrinkite, ar taikytojuje nelaukia klaida, nes vienas nepavykęs įvykis sustabdo eigą, o gavėjas toliau praneša apie ryšį. Tada užfiksuokite įrodymus: kanalo pavadinimą, abiejų etapų būsenas, įvykdytą poziciją ir laiką. Žalias indikatorius yra teiginys; pozicija yra faktas.