MySQL-replikering etter eit VPN-brot: les båe trinna først

Replikeringsovervaking blir raud når VPN-en fell, og instinktet er å nullstilla ein posisjon. Det instinktet er måten eit nettverksbrot blir eit dataproblem. Ein broten veg seier ingenting om kva replikaen har motteke eller brukt, og det er to trinn med to tilstandar. Les dei kvar for seg før du endrar noko.

To trinn, to separate svar

Ein vanleg asynkron replika gjer to jobbar. Mottakaren koplar til kjelda, trekkjer hendingar og skriv dei lokalt til relay-loggen. Brukaren les den loggen og køyrer hendingane mot replikaen. Når vegen bryt, stoppar mottakaren straks, medan brukaren held fram med å arbeide gjennom etterslepet som alt ligg på disken. Eitt avbrot gir derfor to ulike spørsmål: er sambandet tilbake, og er det oppsamla arbeidet brukt? Behandlar ein dei som eitt spørsmål, blir to tilstandar gjennomsnittleg gjort om til eit misvisande svar.

At mottakaren kjem seg, fortel at vegen er oppe. Det seier ingenting om kor langt brukaren ligg bak, eller om han trefte ein feil medan han var fråkopla.

Les kanalen med rett setning

På MySQL 8.4 returnerer SHOW REPLICA STATUS éi rad per konfigurerte kanal, så les rada for kanalen du meiner, ikkje den første i lista. Replica_IO_Running skil ein tilkopla mottakar frå ein som koplar til eller er stoppa, og Replica_SQL_Running skildrar brukaren. Les feilkolonnane ved sida av, fordi ein mottakar som koplar til på nytt og feilar straks, etterlèt ei melding som ingen statusflagg vil visa. Eldre utgåver brukar andre kolonnenamn, så ikkje omset ei gammal oppskrift berre ved å gje kommandoane nye namn.

Kontroller òg identiteten til kjelda og eventuelle konfigurerte filter. Ein replika som peikar på feil kjelde, eller er filtrert trongare enn du trur, rapporterer helse medan han replikerer noko anna enn det du ventar.

Kvifor eit null-forsinkelsetal kan ljuga

Forsinkelsesverdien samanliknar tidsstempelet til den sist brukte hendinga med gjeldande tid. Når mottakaren har vore stoppa i ein time, kan brukaren arbeide gjennom etterslepet og nå slutten av det han tok imot, og då fell talet til null sjølv om replikaen er ein time bak kjelda. Metrikken måler køen til brukaren, ikkje aktualiteten til replikaen.

Samanlikn i staden utførte transaksjonar med det kjelda har tilgjengeleg. Den samanlikninga overlever ein fastlåst mottakar.

Oppbevaringa avgjer det reelle gjenopprettingsvindauget

Innhenting krev at kjelda framleis held på transaksjonane replikaen treng. Når dei er rensa, kan replikaen ikkje hente dei, og inga mengd gjenoppkopling endrar det.

Med GTID-autoposisjonering er feilen eksplisitt: replikaen ber om historikk kjelda ikkje lenger har, og nektar å halde fram. Vala er då å hente dei manglande hendingane frå ei kjelde som framleis har dei, eller å byggje opp att frå ein tryggingskopi og la han hente inn. Å hoppe over gapet er ikkje å hente inn, og det etterlèt ein replika der dataa stille er ufullstendige. Planlegg vindauget ved å samanlikne venta avbrotslengd med binærlogg-oppbevaring på kjelda og endringstakta, fordi dei tre tala avgjer om eit avbrot i det heile kan gjenopprettast.

Verifiser innhentinga, ikkje fargen på ein indikator

Gjenopprett vegen, inkludert namneoppslag og transporttryggleik, og sjå deretter om den eksisterande kanalen koplar til på nytt etter sin eigen policy. Gje han eit definert intervall før du grip inn, og registrer framdrifta for mottak og bruk i båe endar av intervallet. Ein kanal som startar på nytt, og ein kanal som er ajour, er ulike funn.

Stadfest at brukaren har nådd gjeldande posisjon til kjelda, ikkje berre slutten av det gamle etterslepet. Kontroller at ingen feil ventar i brukaren, fordi éi mislukka hending stoppar framdrifta medan mottakaren held fram med å rapportere tilkopling. Registrer deretter prova: kanalnamn, tilstandane til båe trinna, den utførte posisjonen og tidspunktet. Ein grøn indikator er ein påstand; posisjonen er eit faktum.