Replikacija MySQL po prekinitvi VPN: najprej preberite obe stopnji

Spremljanje replikacije postane rdeče, ko VPN pade, in nagon je ponastaviti položaj. Prav ta nagon spremeni omrežno prekinitev v podatkovno težavo. Prekinjena pot ne pove ničesar o tem, kaj je replika prejela ali uporabila, in to sta dve stopnji z dvema stanjema. Preberite ju ločeno, preden karkoli spremenite.

Dve stopnji, dva ločena odgovora

Običajna asinhrona replika opravi dve deli. Sprejemnik se poveže z virom, potegne dogodke in jih lokalno zapiše v dnevnik posredovanja. Izvajalec bere ta dnevnik in izvaja dogodke na repliki. Ko se pot pretrga, se sprejemnik takoj ustavi, medtem ko izvajalec še naprej obdeluje zaostanek, ki je že na disku. Ena prekinitev torej ustvari dve različni vprašanji: ali se je povezava vrnila in ali je bilo nakopičeno delo uporabljeno? Če ju obravnavamo kot eno vprašanje, se dve stanji povprečita v zavajajoč odgovor.

Obnovitev sprejemnika pove, da je pot aktivna. Ne pove ničesar o tem, koliko izvajalec zaostaja, niti ali je med odklopom naletel na napako.

Berite kanal s pravilno izjavo

V MySQL 8.4 SHOW REPLICA STATUS vrne eno vrstico za vsak konfiguriran kanal, zato berite vrstico kanala, ki ga mislite, in ne prve na seznamu. Replica_IO_Running loči povezan sprejemnik od tistega, ki se povezuje ali je ustavljen, Replica_SQL_Running pa opisuje izvajalec. Berite ob tem tudi stolpce z napakami, ker sprejemnik, ki se znova poveže in takoj spodleti, pusti sporočilo, ki ga nobena statusna zastavica ne bo pokazala. Starejše izdaje uporabljajo druga imena stolpcev, zato starega recepta ne prevajajte samo s preimenovanjem ukazov.

Preverite tudi identiteto vira in vse konfigurirane filtre. Replika, usmerjena na napačen vir ali filtrirana ožje, kot mislite, poroča o zdravju, medtem ko replicira nekaj drugega, kot pričakujete.

Zakaj lahko ničelni zaostanek laže

Vrednost zaostanka primerja časovni žig zadnjega uporabljenega dogodka s trenutnim časom. Ko je bil sprejemnik ustavljen eno uro, lahko izvajalec obdela zaostanek in doseže konec prejetega, nato pa številka pade na nič, čeprav replika za virom zaostaja eno uro. Metrika meri čakalno vrsto izvajalca, ne ažurnosti replike.

Namesto tega primerjajte izvedene transakcije s tem, kar ima vir na voljo. Ta primerjava preživi zataknjen sprejemnik.

Dejansko okno obnovitve določa hramba

Za dohitevanje mora vir še vedno hraniti transakcije, ki jih replika potrebuje. Ko so te počiščene, jih replika ne more pridobiti in nobeno ponovno povezovanje tega ne spremeni.

Pri samodejnem pozicioniranju GTID je napaka jasna: replika zahteva zgodovino, ki je vir ne hrani več, in noče nadaljevati. Možnosti so potem pridobiti manjkajoče dogodke iz vira, ki jih še ima, ali obnoviti iz varnostne kopije in ji pustiti, da dohiti. Preskok vrzeli ni dohitevanje in pusti repliko, katere podatki so tiho nepopolni. Načrtujte okno s primerjavo pričakovane dolžine prekinitve s hrambo binarnega dnevnika na viru in hitrostjo sprememb, ker te tri številke odločajo, ali je prekinitev sploh obnovljiva.

Preverjajte dohitevanje, ne barve indikatorja

Obnovite pot, vključno z razreševanjem imen in varnostjo prenosa, nato opazujte, ali se obstoječi kanal znova poveže po lastni politiki. Dajte mu določen interval, preden posredujete, in na obeh koncih tega intervala zabeležite napredek sprejemanja in uporabe. Kanal, ki se znova zažene, in kanal, ki je ažuren, sta različni ugotovitvi.

Potrdite, da je izvajalec dosegel trenutni položaj vira, ne le konca starega zaostanka. Preverite, da v izvajalcu ne čaka napaka, ker en neuspešen dogodek ustavi napredek, medtem ko sprejemnik še naprej poroča o povezavi. Nato zabeležite dokaze: ime kanala, stanji obeh stopenj, izvedeni položaj in čas. Zelen indikator je trditev; položaj je dejstvo.