MySQL-ripetado post VPN-interrompo: unue legu ambaŭ etapojn

La monitorado de ripetado ruĝiĝas kiam la VPN falas, kaj la instinkto estas restarigi pozicion. Ĝuste tiu instinkto igas retinterrompon datuma problemo. Falinta vojo diras nenion pri tio, kion la kopio ricevis aŭ aplikis, kaj tio estas du etapoj kun du statoj. Legu ilin aparte antaŭ ol ŝanĝi ion ajn.

Du etapoj, du apartaj respondoj

Ordinara nesinkrona kopio faras du taskojn. La ricevilo konektiĝas al la fonto, eltiras eventojn kaj skribas ilin loke en la relajan protokolon. La aplikaĵo legas tiun relajan protokolon kaj plenumas la eventojn sur la kopio. Kiam la vojo rompiĝas, la ricevilo tuj haltas, dum la aplikaĵo daŭre prilaboras la restaron, kiu jam estas sur la disko. Unu interrompo do produktas du malsamajn demandojn: ĉu la konekto revenis, kaj ĉu la amasigita laboro estis aplikita? Trakti ilin kiel unu demandon mezumas du statojn en misgvida respondo.

La resaniĝo de la ricevilo diras al vi, ke la vojo funkcias. Ĝi diras nenion pri tio, kiom malantaŭe estas la aplikaĵo, nek ĉu ĝi trafis eraron dum la malkonekto.

Legu la kanalon per la ĝusta komando

En MySQL 8.4, SHOW REPLICA STATUS redonas unu vicon por ĉiu agordita kanalo, do legu la vicon de la kanalo, kiun vi celas, anstataŭ la unuan en la listo. Replica_IO_Running distingas konektitan ricevilon disde unu, kiu konektiĝas aŭ estas haltigita, kaj Replica_SQL_Running priskribas la aplikaĵon. Legu la erarajn kolumnojn apude, ĉar ricevilo, kiu rekonektiĝas kaj tuj malsukcesas, lasas mesaĝon, kiun neniu statusa flago montros. Pli malnovaj eldonoj uzas aliajn kolumnomojn, do ne traduku malnovan recepton nur renomante la komandojn.

Kontrolu ankaŭ la identecon de la fonto kaj ĉiujn agorditajn filtrilojn. Kopio direktita al la malĝusta fonto, aŭ filtrita pli mallarĝe ol vi pensas, raportas sanon dum ĝi ripetas ion alian ol vi atendas.

Kial nula malfrua nombro povas mensogi

La malfrua valoro komparas la tempostampon de la laste aplikita evento kun la nuna tempo. Kiam la ricevilo estis haltigita dum unu horo, la aplikaĵo povas prilabori la restaron kaj atingi la finon de tio, kion ĝi ricevis, kaj tiam la nombro falas al nulo, kvankam la kopio estas unu horon malantaŭe de la fonto. La mezuro mezuras la atendovicon de la aplikaĵo, ne la aktualecon de la kopio.

Anstataŭe komparu plenumitajn transakciojn kun tio, kion la fonto havas disponeble. Tiu komparo postvivas haltintan ricevilon.

La konservado difinas la realan reakiran fenestron

Atingi postulon postulas, ke la fonto ankoraŭ tenu la transakciojn, kiujn la kopio bezonas. Post kiam ili estas forigitaj, la kopio ne povas akiri ilin, kaj neniu kvanto da rekonektado tion ŝanĝas.

Kun GTID-aŭtomata poziciigo la malsukceso estas eksplicita: la kopio petas historion, kiun la fonto jam ne tenas, kaj rifuzas daŭrigi. La elektoj tiam estas akiri la mankantajn eventojn de fonto, kiu ankoraŭ havas ilin, aŭ rekonstrui el savkopio kaj lasi ĝin atingi postulon. Preterpasi la breĉon ne estas atingi postulon, kaj ĝi lasas kopion, kies datumoj estas silente nekompletaj. Planu la fenestron komparante la atendatan daŭron de la interrompo kun la konservado de la binara protokolo ĉe la fonto kaj la ŝanĝa rapideco, ĉar tiuj tri nombroj decidas, ĉu interrompo entute estas reakirebla.

Kontrolu la postatingon, ne la koloron de indikilo

Restarigu la vojon, inkluzive de nomresolucio kaj transporta sekureco, poste observu, ĉu la ekzistanta kanalo rekonektiĝas laŭ sia propra politiko. Donu al ĝi difinitan intervalon antaŭ ol interveni, kaj registru la progreson de ricevo kaj apliko ĉe ambaŭ finoj de tiu intervalo. Kanalo, kiu restartas, kaj kanalo, kiu estas aktuala, estas malsamaj konkludoj.

Konfirmu, ke la aplikaĵo atingis la nunan pozicion de la fonto, ne nur la finon de la malnova restaro. Kontrolu, ke neniu eraro atendas en la aplikaĵo, ĉar unu malsukcesa evento haltigas progreson, dum la ricevilo daŭre raportas konekton. Poste registru la pruvojn: kanala nomo, ambaŭ etapaj statoj, la plenumita pozicio kaj la tempo. Verda indikilo estas aserto; la pozicio estas fakto.