MySQL-replikering etter et VPN-brudd: les begge trinnene først

Replikeringsovervåking blir rød når VPN-en faller, og instinktet er å nullstille en posisjon. Det instinktet er måten et nettverksbrudd blir et dataproblem. En brutt vei sier ingenting om hva replikaen har mottatt eller anvendt, og det er to trinn med to tilstander. Les dem hver for seg før du endrer noe.

To trinn, to separate svar

En vanlig asynkron replika gjør to jobber. Mottakeren kobler til kilden, trekker hendelser og skriver dem lokalt til relay-loggen. Anvenderen leser den loggen og kjører hendelsene mot replikaen. Når veien brytes, stopper mottakeren umiddelbart, mens anvenderen fortsetter å jobbe gjennom etterslepet som allerede ligger på disken. Ett avbrudd gir derfor to forskjellige spørsmål: er forbindelsen tilbake, og er det oppsamlede arbeidet anvendt? Behandler man dem som ett spørsmål, gjennomsnittes to tilstander til et misvisende svar.

At mottakeren kommer seg, forteller at veien er oppe. Det sier ingenting om hvor langt anvenderen ligger bak, eller om den traff en feil mens den var frakoblet.

Les kanalen med riktig setning

På MySQL 8.4 returnerer SHOW REPLICA STATUS én rad per konfigurerte kanal, så les raden for kanalen du mener, ikke den første i listen. Replica_IO_Running skiller en tilkoblet mottaker fra en som kobler til eller er stoppet, og Replica_SQL_Running beskriver anvenderen. Les feilkolonnene ved siden av, fordi en mottaker som kobler til på nytt og feiler umiddelbart, etterlater en melding som ingen statusflagg vil vise. Eldre utgivelser bruker andre kolonnenavn, så ikke oversett en gammel oppskrift ved bare å gi kommandoene nye navn.

Kontroller også kildens identitet og eventuelle konfigurerte filtre. En replika som peker på feil kilde, eller er filtrert snevrere enn du tror, rapporterer sunnhet mens den replikerer noe annet enn det du forventer.

Hvorfor et null-forsinkelsestall kan lyve

Forsinkelsesverdien sammenligner tidsstempelet til den sist anvendte hendelsen med gjeldende tid. Når mottakeren har vært stoppet i en time, kan anvenderen jobbe gjennom etterslepet og nå slutten av det den mottok, og da faller tallet til null selv om replikaen er en time bak kilden. Metrikken måler anvenderens kø, ikke replikaens aktualitet.

Sammenlign i stedet utførte transaksjoner med det kilden har tilgjengelig. Den sammenligningen overlever en fastlåst mottaker.

Oppbevaringen bestemmer det reelle gjenopprettingsvinduet

Innhenting krever at kilden fortsatt beholder transaksjonene replikaen trenger. Når de er renset, kan replikaen ikke hente dem, og ingen mengde gjenoppkobling endrer det.

Med GTID-autoposisjonering er feilen eksplisitt: replikaen ber om historikk kilden ikke lenger har, og nekter å fortsette. Valgene er da å hente de manglende hendelsene fra en kilde som fortsatt har dem, eller å bygge på nytt fra en sikkerhetskopi og la den hente inn. Å hoppe over gapet er ikke å hente inn, og det etterlater en replika der dataene stille er ufullstendige. Planlegg vinduet ved å sammenligne forventet avbruddslengde med binærlogg-oppbevaring på kilden og endringstakten, fordi de tre tallene avgjør om et avbrudd i det hele tatt kan gjenopprettes.

Verifiser innhentingen, ikke fargen på en indikator

Gjenopprett veien, inkludert navneoppslag og transportsikkerhet, og se deretter om den eksisterende kanalen kobler til på nytt etter sin egen policy. Gi den et definert intervall før du griper inn, og registrer fremdriften for mottak og anvendelse i begge ender av intervallet. En kanal som starter på nytt, og en kanal som er ajour, er forskjellige funn.

Bekreft at anvenderen har nådd kildens gjeldende posisjon, ikke bare slutten av det gamle etterslepet. Kontroller at ingen feil venter i anvenderen, fordi én mislykket hendelse stopper fremdriften mens mottakeren fortsetter å rapportere tilkobling. Registrer deretter bevisene: kanalnavn, begge trinns tilstander, den utførte posisjonen og tidspunktet. En grønn indikator er en påstand; posisjonen er et faktum.