MySQL-replikaatio VPN-yhteyden katkettua: lue ensin molemmat vaiheet

Replikaation valvonta muuttuu punaiseksi, kun VPN katkeaa, ja vaisto on nollata sijainti. Juuri tämä vaisto muuttaa verkkokatkoksen tieto-ongelmaksi. Katkennut polku ei kerro mitään siitä, mitä replika on vastaanottanut tai soveltanut, ja ne ovat kaksi vaihetta, joilla on kaksi tilaa. Lue ne erikseen ennen kuin muutat mitään.

Kaksi vaihetta, kaksi erillistä vastausta

Tavanomainen asynkroninen replika tekee kaksi työtä. Vastaanottaja yhdistää lähteeseen, vetää tapahtumat ja kirjoittaa ne paikallisesti välityslokiin. Soveltaja lukee tämän välityslokin ja suorittaa tapahtumat replikalla. Kun polku katkeaa, vastaanottaja pysähtyy heti, kun taas soveltaja jatkaa jo levyllä olevan jonon käsittelyä. Yksi katkos tuottaa siis kaksi eri kysymystä: onko yhteys palannut ja onko kertynyt työ sovellettu? Jos ne käsitellään yhtenä kysymyksenä, kaksi tilaa keskiarvoistuu harhaanjohtavaksi vastaukseksi.

Vastaanottajan toipuminen kertoo, että polku on pystyssä. Se ei kerro mitään siitä, kuinka paljon soveltaja on jäljessä tai kohtasiko se virheen yhteyden ollessa poikki.

Lue kanava oikealla lauseella

MySQL 8.4:ssä SHOW REPLICA STATUS palauttaa yhden rivin jokaista määritettyä kanavaa kohden, joten lue haluamasi kanavan rivi etkä luettelon ensimmäistä. Replica_IO_Running erottaa yhdistetyn vastaanottajan sellaisesta, joka yhdistää tai on pysäytetty, ja Replica_SQL_Running kuvaa soveltajan. Lue virhesarakkeet niiden vierestä, sillä vastaanottaja, joka yhdistää uudelleen ja epäonnistuu heti, jättää viestin, jota mikään tilalippu ei näytä. Vanhemmat versiot käyttävät eri sarakenimiä, joten älä käännä vanhaa ohjetta pelkästään nimeämällä komennot uudelleen.

Tarkista myös lähteen identiteetti ja kaikki määritetyt suodattimet. Väärään lähteeseen osoitettu tai luultua kapeammin suodatettu replika raportoi terveyttä samalla kun se replikoi jotain muuta kuin odotat.

Miksi nollaviive voi valehdella

Viivearvo vertaa viimeksi sovelletun tapahtuman aikaleimaa nykyiseen aikaan. Kun vastaanottaja on ollut pysäytettynä tunnin, soveltaja voi käsitellä jonon ja saavuttaa vastaanotetun lopun, jolloin luku putoaa nollaan, vaikka replika on tunnin lähdettä jäljessä. Mittari mittaa soveltajan jonoa, ei replikan ajantasaisuutta.

Vertaa sen sijaan suoritettuja tapahtumia siihen, mitä lähteellä on saatavilla. Tämä vertailu kestää pysähtyneen vastaanottajan.

Säilytys määrittää todellisen palautumisikkunan

Kiinni ottaminen edellyttää, että lähde yhä säilyttää tapahtumat, joita replika tarvitsee. Kun ne on puhdistettu, replika ei voi noutaa niitä, eikä mikään määrä uudelleenyhdistämistä muuta sitä.

GTID-automaattisijainnissa vika on selkeä: replika pyytää historiaa, jota lähde ei enää säilytä, ja kieltäytyy jatkamasta. Vaihtoehdot ovat silloin puuttuvien tapahtumien hakeminen lähteestä, jolla niitä vielä on, tai uudelleenrakentaminen varmuuskopiosta ja sen annetaan ottaa kiinni. Aukon ohittaminen ei ole kiinni ottamista, ja se jättää replikan, jonka tiedot ovat hiljaa vaillinaiset. Suunnittele ikkuna vertaamalla odotettua katkoksen kestoa lähteen binäärilokin säilytykseen ja muutosnopeuteen, koska nämä kolme lukua ratkaisevat, onko katkos ylipäätään palautettavissa.

Varmista kiinni ottaminen, älä ilmaisimen väriä

Palauta polku, mukaan lukien nimien selvitys ja tiedonsiirron turvallisuus, ja seuraa sitten, yhdistääkö olemassa oleva kanava uudelleen oman käytäntönsä mukaisesti. Anna sille määritetty aikaväli ennen väliintuloa ja kirjaa vastaanoton ja soveltamisen edistyminen tämän aikavälin molemmissa päissä. Uudelleen käynnistyvä kanava ja ajan tasalla oleva kanava ovat eri havaintoja.

Vahvista, että soveltaja on saavuttanut lähteen nykyisen sijainnin, ei vain vanhan jonon loppua. Tarkista, ettei soveltajassa odota virhe, sillä yksi epäonnistunut tapahtuma pysäyttää edistymisen, kun taas vastaanottaja jatkaa yhdistettynä raportoimista. Kirjaa sitten todisteet: kanavan nimi, molempien vaiheiden tilat, suoritettu sijainti ja aika. Vihreä ilmaisin on väite; sijainti on tosiasia.