MySQL-replikering efter ett VPN-avbrott: läs båda stegen först

Replikeringens övervakning blir röd när VPN:en faller, och instinkten är att återställa en position. Den instinkten är hur ett nätavbrott blir ett dataproblem. En bruten väg säger ingenting om vad repliken har tagit emot eller tillämpat, och det är två steg med två tillstånd. Läs dem var för sig innan du ändrar något.

Två steg, två separata svar

En vanlig asynkron replik gör två jobb. Mottagaren ansluter till källan, hämtar händelser och skriver dem lokalt till relay-loggen. Tillämparen läser den loggen och kör händelserna mot repliken. När vägen bryts stannar mottagaren omedelbart medan tillämparen fortsätter att arbeta igenom eftersläpningen som redan ligger på disken. Ett avbrott ger därför två olika frågor: är anslutningen tillbaka, och har det uppsamlade arbetet tillämpats? Behandlar man dem som en fråga medelvärdesbildas två tillstånd till ett missvisande svar.

Att mottagaren återhämtar sig säger att vägen är uppe. Det säger ingenting om hur långt efter tillämparen är, eller om den stötte på ett fel medan den var frånkopplad.

Läs kanalen med rätt sats

På MySQL 8.4 returnerar SHOW REPLICA STATUS en rad per konfigurerad kanal, så läs raden för den kanal du menar och inte den första i listan. Replica_IO_Running skiljer en ansluten mottagare från en som ansluter eller är stoppad, och Replica_SQL_Running beskriver tillämparen. Läs felkolumnerna bredvid, eftersom en mottagare som återansluter och misslyckas direkt lämnar ett meddelande som ingen statusflagga visar. Äldre versioner använder andra kolumnnamn, så översätt inte ett gammalt recept genom att bara byta namn på kommandona.

Kontrollera också källans identitet och eventuella konfigurerade filter. En replik som pekar på fel källa, eller är filtrerad snävare än du tror, rapporterar hälsa medan den replikerar något annat än du förväntar dig.

Varför en nollfördröjning kan ljuga

Fördröjningsvärdet jämför tidsstämpeln för den senast tillämpade händelsen med aktuell tid. När mottagaren har varit stoppad i en timme kan tillämparen arbeta igenom eftersläpningen och nå slutet av det den tog emot, och då faller talet till noll trots att repliken är en timme efter källan. Måttet mäter tillämparens kö, inte replikens aktualitet.

Jämför i stället utförda transaktioner med vad källan har tillgängligt. Den jämförelsen överlever en fastnad mottagare.

Bevarandet bestämmer det verkliga återställningsfönstret

Att komma ikapp kräver att källan fortfarande behåller de transaktioner repliken behöver. När de har rensats kan repliken inte hämta dem, och ingen mängd återanslutning ändrar det.

Med GTID-autopositionering är felet explicit: repliken begär historik som källan inte längre har och vägrar fortsätta. Alternativen är då att hämta de saknade händelserna från en källa som fortfarande har dem, eller att bygga om från en säkerhetskopia och låta den komma ikapp. Att hoppa över gapet är inte att komma ikapp, och det lämnar en replik vars data tyst är ofullständiga. Planera fönstret genom att jämföra förväntad avbrottslängd med binärloggens bevarande på källan och ändringstakten, eftersom de tre talen avgör om ett avbrott alls går att återställa.

Verifiera ikappkommandet, inte färgen på en indikator

Återställ vägen, inklusive namnuplösning och transportsäkerhet, och se sedan om den befintliga kanalen återansluter enligt sin egen policy. Ge den ett definierat intervall innan du ingriper, och registrera framstegen för mottagning och tillämpning i båda ändarna av det intervallet. En kanal som startar om och en kanal som är aktuell är olika fynd.

Bekräfta att tillämparen har nått källans aktuella position, inte bara slutet av den gamla eftersläpningen. Kontrollera att inget fel väntar i tillämparen, eftersom en enda misslyckad händelse stoppar framdriften medan mottagaren fortsätter att rapportera anslutning. Registrera sedan bevisen: kanalnamn, båda stegens tillstånd, den utförda positionen och tiden. En grön indikator är ett påstående; positionen är ett faktum.