MySQL-replikering efter et VPN-nedbrud: læs begge trin først

Replikeringsovervågning bliver rød, når VPN falder, og instinktet er at nulstille en position. Det instinkt er måden, hvorpå en netværksafbrydelse bliver et dataproblem. En nedbrudt vej siger intet om, hvad replikaen har modtaget eller anvendt, og det er to trin med to tilstande. Læs dem hver for sig, før du ændrer noget.

To trin, to separate svar

En almindelig asynkron replika udfører to job. Modtageren forbinder til kilden, trækker hændelser og skriver dem til relay-loggen lokalt. Anvenderen læser den relay-log og udfører hændelserne mod replikaen. Når vejen bryder sammen, stopper modtageren øjeblikkeligt, mens anvenderen fortsætter med at arbejde gennem det efterslæb, der allerede ligger på disken. Et nedbrud giver derfor to forskellige spørgsmål: er forbindelsen tilbage, og er det akkumulerede arbejde anvendt? Behandler man dem som ét spørgsmål, gennemsnitter to tilstande til et misvisende svar.

At modtageren kommer sig, fortæller dig, at vejen er oppe. Det siger intet om, hvor langt anvenderen er bagud, eller om den ramte en fejl, mens den var afbrudt.

Læs kanalen med den rigtige sætning

På MySQL 8.4 returnerer SHOW REPLICA STATUS én række for hver konfigureret kanal, så læs rækken for den kanal, du mener, i stedet for den første på listen. Replica_IO_Running skelner en forbundet modtager fra en, der forbinder eller er stoppet, og Replica_SQL_Running beskriver anvenderen. Læs fejlkolonnerne ved siden af, fordi en modtager, der genopretter forbindelsen og straks fejler, efterlader en besked, som ingen statusflag vil vise. Ældre udgivelser bruger andre kolonnenavne, så oversæt ikke en gammel opskrift ved blot at omdøbe kommandoerne.

Kontrollér også kildens identitet og eventuelle konfigurerede filtre. En replika, der peger på den forkerte kilde eller er filtreret snævrere, end du tror, rapporterer sundhed, mens den replikerer noget andet end det, du forventer.

Hvorfor et nul-forsinkelsestal kan lyve

Forsinkelsesværdien sammenligner tidsstemplet for den sidste anvendte hændelse med den aktuelle tid. Når modtageren har været stoppet i en time, kan anvenderen arbejde gennem efterslæbet og nå slutningen af det, den har modtaget, og så falder tallet til nul, selvom replikaen er en time bagud i forhold til kilden. Metrikken måler anvenderens kø, ikke replikaens aktualitet.

Sammenlign i stedet udførte transaktioner med det, kilden har tilgængeligt. Den sammenligning overlever en fastlåst modtager.

Opbevaring fastlægger det reelle gendannelsesvindue

Indhentning kræver, at kilden stadig har de transaktioner, replikaen har brug for. Når de er ryddet, kan replikaen ikke hente dem, og ingen mængde genopretning af forbindelsen ændrer det.

Med GTID-autopositionering er fejlen eksplicit: replikaen beder om historie, som kilden ikke længere har, og nægter at fortsætte. Valgmulighederne er så at hente de manglende hændelser fra en kilde, der stadig har dem, eller at genopbygge fra en sikkerhedskopi og lade den indhente. At springe hullet over er ikke at indhente, og det efterlader en replika, hvis data stille og roligt er ufuldstændige. Planlæg vinduet ved at sammenligne forventet nedbrudsvarighed med binærlog-opbevaring på kilden og ændringshastigheden, fordi de tre tal afgør, om et nedbrud overhovedet kan gendannes.

Verificér indhentning, ikke farven på en indikator

Gendan vejen, inklusive navneopløsning og transportsikkerhed, og se derefter, om den eksisterende kanal genopretter forbindelsen efter sin egen politik. Giv den et defineret interval, før du griber ind, og registrér modtagelses- og anvendelsesfremskridt i begge ender af det interval. En kanal, der genstarter, og en kanal, der er aktuel, er forskellige fund.

Bekræft, at anvenderen har nået kildens aktuelle position, ikke blot slutningen af det gamle efterslæb. Kontrollér, at der ikke venter en fejl i anvenderen, fordi én mislykket hændelse stopper fremskridtet, mens modtageren fortsat rapporterer at være forbundet. Registrér derefter beviserne: kanalnavn, begge trins tilstande, den udførte position og tidspunktet. En grøn indikator er en påstand; positionen er et faktum.