Replikace MySQL po výpadku VPN: nejprve čtěte obě fáze

Monitorování replikace zčervená, když VPN vypadne, a instinkt je resetovat pozici. Právě tento instinkt mění síťový výpadek v problém s daty. Přerušená cesta nic neříká o tom, co replika přijala nebo aplikovala, a to jsou dvě fáze se dvěma stavy. Čtěte je odděleně, než cokoli změníte.

Dvě fáze, dvě samostatné odpovědi

Běžná asynchronní replika dělá dvě práce. Příjemce se připojí ke zdroji, stáhne události a zapíše je lokálně do relay logu. Aplikátor tento relay log čte a provádí události na replice. Když se cesta přeruší, příjemce se okamžitě zastaví, zatímco aplikátor dál zpracovává backlog, který už je na disku. Jeden výpadek tak vytváří dvě různé otázky: vrátilo se spojení a byla nahromaděná práce aplikována? Když je bereme jako jednu otázku, dva stavy se zprůměrují do zavádějící odpovědi.

Obnova příjemce říká, že cesta funguje. Neříká nic o tom, jak daleko je aplikátor pozadu, ani zda při odpojení narazil na chybu.

Čtěte kanál správným příkazem

V MySQL 8.4 vrací SHOW REPLICA STATUS jeden řádek na každý nakonfigurovaný kanál, takže čtěte řádek kanálu, který máte na mysli, ne první v seznamu. Replica_IO_Running odlišuje připojeného příjemce od toho, který se připojuje nebo je zastaven, a Replica_SQL_Running popisuje aplikátor. Čtěte vedle nich sloupce s chybami, protože příjemce, který se znovu připojí a hned selže, zanechá zprávu, kterou žádný stavový příznak neukáže. Starší verze používají jiná jména sloupců, takže nechte starý recept přeložit pouhým přejmenováním příkazů.

Zkontrolujte také identitu zdroje a všechny nakonfigurované filtry. Replika namířená na špatný zdroj nebo filtrovaná úžeji, než si myslíte, hlásí zdraví, zatímco replikuje něco jiného, než očekáváte.

Proč může nulové zpoždění lhát

Hodnota zpoždění porovnává časové razítko poslední aplikované události s aktuálním časem. Když byl příjemce hodinu zastaven, aplikátor může zpracovat backlog a dostat se na konec toho, co přijal, a číslo pak spadne na nulu, i když replika hodinu za zdrojem zaostává. Metrika měří frontu aplikátoru, ne aktuálnost repliky.

Porovnejte místo toho provedené transakce s tím, co má zdroj k dispozici. Takové srovnání přežije zaseknutého příjemce.

Skutečné okno obnovy určuje retence

Dohnání vyžaduje, aby zdroj stále uchovával transakce, které replika potřebuje. Jakmile jsou smazány, replika je nemůže stáhnout a žádné opakované připojování to nezmění.

S automatickým umístěním GTID je selhání explicitní: replika žádá historii, kterou zdroj už neuchovává, a odmítá pokračovat. Možnosti pak jsou získat chybějící události ze zdroje, který je ještě má, nebo obnovit ze zálohy a nechat ji dohnat. Přeskočení mezery není dohnání a zanechá repliku, jejíž data jsou tiše neúplná. Naplánujte okno porovnáním očekávané délky výpadku s retencí binárního logu na zdroji a tempem změn, protože tato tři čísla rozhodují, zda je výpadek vůbec obnovitelný.

Ověřujte dohnání, ne barvu indikátoru

Obnovte cestu včetně překladu jmen a zabezpečení přenosu a pak sledujte, zda se stávající kanál znovu připojí podle vlastních pravidel. Dejte mu určený interval, než zasáhnete, a na obou koncích tohoto intervalu zaznamenejte průběh příjmu a aplikace. Kanál, který se restartuje, a kanál, který je aktuální, jsou různá zjištění.

Potvrďte, že aplikátor dosáhl aktuální pozice zdroje, ne jen konce starého backlogu. Zkontrolujte, že v aplikátoru nečeká chyba, protože jedna neúspěšná událost zastaví postup, zatímco příjemce dál hlásí připojení. Potom zaznamenejte důkazy: název kanálu, oba stavy fází, provedenou pozici a čas. Zelený indikátor je tvrzení; pozice je fakt.