Replikácia MySQL po výpadku VPN: najprv si prečítajte obe fázy

Monitorovanie replikácie sčervenie, keď vypadne VPN, a inštinkt je resetovať pozíciu. Práve tento inštinkt mení sieťový výpadok na problém s dátami. Prerušená cesta nehovorí nič o tom, čo replika prijala alebo aplikovala, a to sú dve fázy s dvoma stavmi. Prečítajte ich oddelene, skôr než čokoľvek zmeníte.

Dve fázy, dve samostatné odpovede

Bežná asynchrónna replika robí dve práce. Prijímač sa pripojí k zdroju, stiahne udalosti a zapíše ich lokálne do relay logu. Aplikátor tento log číta a vykonáva udalosti na replike. Keď sa cesta preruší, prijímač sa okamžite zastaví, kým aplikátor ďalej spracúva backlog, ktorý už je na disku. Jeden výpadok teda vytvára dve rôzne otázky: vrátilo sa spojenie a bola nahromadená práca aplikovaná? Keď ich berieme ako jednu otázku, dva stavy sa spriemerujú do zavádzajúcej odpovede.

Obnova prijímača hovorí, že cesta funguje. Nehovorí nič o tom, ako ďaleko je aplikátor pozadu, ani či počas odpojenia narazil na chybu.

Čítajte kanál správnym príkazom

V MySQL 8.4 vracia SHOW REPLICA STATUS jeden riadok na každý nakonfigurovaný kanál, takže čítajte riadok kanála, ktorý máte na mysli, nie prvý v zozname. Replica_IO_Running odlišuje pripojený prijímač od toho, ktorý sa pripája alebo je zastavený, a Replica_SQL_Running opisuje aplikátor. Čítajte vedľa nich stĺpce s chybami, pretože prijímač, ktorý sa znova pripojí a hneď zlyhá, zanechá správu, ktorú neukáže žiadna stavová vlajka. Staršie verzie používajú iné názvy stĺpcov, takže neprekladajte starý recept iba premenovaním príkazov.

Skontrolujte aj identitu zdroja a všetky nakonfigurované filtre. Replika namierená na nesprávny zdroj alebo filtrovaná užšie, než si myslíte, hlási zdravie, pričom replikuje niečo iné, než očakávate.

Prečo môže nulové oneskorenie klamať

Hodnota oneskorenia porovnáva časovú pečiatku poslednej aplikovanej udalosti s aktuálnym časom. Keď bol prijímač zastavený hodinu, aplikátor môže spracovať backlog a dostať sa na koniec toho, čo prijal, a číslo potom klesne na nulu, aj keď replika hodinu za zdrojom zaostáva. Metrika meria front aplikátora, nie aktuálnosť repliky.

Namiesto toho porovnajte vykonané transakcie s tým, čo má zdroj k dispozícii. Také porovnanie prežije zaseknutý prijímač.

Skutočné okno obnovy určuje retencia

Dohnať sa dá len vtedy, ak zdroj stále uchováva transakcie, ktoré replika potrebuje. Po ich vymazaní ich replika nemôže získať a žiadne opakované pripájanie to nezmení.

Pri automatickom umiestnení GTID je zlyhanie explicitné: replika žiada históriu, ktorú zdroj už neuchováva, a odmieta pokračovať. Možnosti sú potom získať chýbajúce udalosti zo zdroja, ktorý ich ešte má, alebo obnoviť zo zálohy a nechať ju dohnať. Preskočenie medzery nie je dohnanie a zanechá repliku, ktorej dáta sú ticho neúplné. Naplánujte okno porovnaním očakávanej dĺžky výpadku s retenciou binárneho logu na zdroji a tempom zmien, pretože tieto tri čísla rozhodujú, či je výpadok vôbec obnoviteľný.

Overujte dohnanie, nie farbu indikátora

Obnovte cestu vrátane prekladu mien a zabezpečenia prenosu a potom sledujte, či sa existujúci kanál znova pripojí podľa vlastných pravidiel. Dajte mu určený interval, kým zasiahnete, a na oboch koncoch tohto intervalu zaznamenajte priebeh prijímania a aplikovania. Kanál, ktorý sa reštartuje, a kanál, ktorý je aktuálny, sú rôzne zistenia.

Potvrďte, že aplikátor dosiahol aktuálnu pozíciu zdroja, nielen koniec starého backlogu. Skontrolujte, či v aplikátore nečaká chyba, pretože jedna neúspešná udalosť zastaví postup, kým prijímač ďalej hlási pripojenie. Potom zaznamenajte dôkazy: názov kanála, oba stavy fáz, vykonanú pozíciu a čas. Zelený indikátor je tvrdenie; pozícia je fakt.