MySQL replikacija nakon prekida VPN-a: prvo pročitajte oba stupnja

Nadzor replikacije postaje crven kad VPN padne, a instinkt je resetirati poziciju. Taj instinkt je način na koji mrežni prekid postaje problem s podacima. Prekinut put ne govori ništa o tome što je replika primila ili primijenila, a to su dva stupnja s dva stanja. Pročitajte ih odvojeno prije nego što bilo što promijenite.

Dva stupnja, dva odvojena odgovora

Uobičajena asinkrona replika obavlja dva posla. Prijamnik se spaja na izvor, povlači događaje i zapisuje ih lokalno u relay log. Izvršitelj čita taj relay log i izvodi događaje na replici. Kad se put prekine, prijamnik se odmah zaustavlja, dok izvršitelj nastavlja obrađivati zaostatak koji je već na disku. Jedan prekid zato stvara dva različita pitanja: je li veza vraćena i je li nakupljeni rad primijenjen? Ako ih tretiramo kao jedno pitanje, dva se stanja prosječno stapaju u obmanjujući odgovor.

Oporavak prijamnika govori da je put uspostavljen. Ne govori ništa o tome koliko izvršitelj zaostaje ni je li naišao na grešku dok je bio odspojen.

Čitajte kanal pravom naredbom

Na MySQL 8.4 SHOW REPLICA STATUS vraća jedan redak po konfiguriranom kanalu, pa čitajte redak kanala koji želite, a ne prvi na popisu. Replica_IO_Running razlikuje povezani prijamnik od onog koji se povezuje ili je zaustavljen, a Replica_SQL_Running opisuje izvršitelj. Čitajte stupce s greškama uz njih, jer prijamnik koji se ponovno poveže i odmah padne ostavlja poruku koju nijedna oznaka stanja neće pokazati. Starija izdanja koriste druga imena stupaca, pa ne prevodite stari recept samo preimenovanjem naredbi.

Provjerite i identitet izvora te sve konfigurirane filtre. Replika usmjerena na pogrešan izvor ili filtrirana uže nego što mislite prijavljuje zdravlje dok replicira nešto drugo od očekivanog.

Zašto broj nultog zaostatka može lagati

Vrijednost zaostatka uspoređuje vremensku oznaku posljednjeg primijenjenog događaja sa trenutnim vremenom. Kad je prijamnik stajao sat vremena, izvršitelj može obraditi zaostatak i doći do kraja onoga što je primio, a tada broj pada na nulu iako replika zaostaje sat za izvorom. Mjera mjeri red izvršitelja, a ne aktualnost replike.

Usporedite umjesto toga izvršene transakcije s onim što izvor ima na raspolaganju. Ta usporedba preživljava zaustavljeni prijamnik.

Stvarni prozor oporavka određuje zadržavanje

Sustizanje zahtijeva da izvor još drži transakcije koje replika treba. Kad se one uklone, replika ih ne može dohvatiti i nikakvo ponovno povezivanje to ne mijenja.

S GTID automatskim pozicioniranjem kvar je jasan: replika traži povijest koju izvor više ne drži i odbija nastaviti. Opcije su tada uzeti nedostajuće događaje s izvora koji ih još ima ili ponovno izgraditi iz sigurnosne kopije i pustiti je da sustigne. Preskakanje praznine nije sustizanje i ostavlja repliku čiji su podaci tiho nepotpuni. Planirajte prozor usporedbom očekivanog trajanja prekida sa zadržavanjem binarnog zapisa na izvoru i brzinom promjena, jer ta tri broja odlučuju je li prekid uopće nadoknadiv.

Provjerite sustizanje, a ne boju pokazatelja

Vratite put, uključujući razrješavanje imena i sigurnost prijenosa, pa gledajte hoće li se postojeći kanal sam ponovno povezati po svojoj politici. Dajte mu određeni interval prije intervencije i zabilježite napredak primanja i primjene na oba kraja tog intervala. Kanal koji se ponovno pokreće i kanal koji je aktualan različiti su nalazi.

Potvrdite da je izvršitelj dosegnuo trenutnu poziciju izvora, a ne samo kraj starog zaostatka. Provjerite ne čeka li u izvršitelju greška, jer jedan neuspjeli događaj zaustavlja napredak dok prijamnik nastavlja izvještavati o povezanosti. Zatim zabilježite dokaze: naziv kanala, stanja oba stupnja, izvršenu poziciju i vrijeme. Zelena oznaka je tvrdnja; pozicija je činjenica.