Replikasie-monitering word rooi wanneer die VPN val, en die instink is om 'n posisie te herstel. Daardie instink is hoe 'n netwerkonderbreking 'n dataprobleem word. 'n Pad wat wegval sê niks oor wat die replika ontvang of toegepas het nie, en dit is twee stadiums met twee toestande. Lees hulle afsonderlik voordat jy enigiets verander.

Twee stadiums, twee afsonderlike antwoorde

'n Konvensionele asinchrone replika doen twee take. Die ontvanger koppel aan die bron, trek gebeure en skryf hulle plaaslik na die afloslog. Die toepasser lees daardie afloslog en voer die gebeure teen die replika uit. Wanneer die pad breek, stop die ontvanger onmiddellik terwyl die toepasser voortgaan met die agterstand wat reeds op skyf is. Een onderbreking lewer dus twee verskillende vrae: is die verbinding terug, en is die opgehoopte werk toegepas? Om hulle as een vraag te behandel, vermeng twee toestande tot 'n misleidende antwoord.

Die ontvanger wat herstel, sê die pad is op. Dit sê niks oor hoe ver die toepasser agter is nie, of of dit 'n fout getref het terwyl dit ontkoppel was.

Lees die kanaal met die regte stelling

Op MySQL 8.4 gee SHOW REPLICA STATUS een ry per gekonfigureerde kanaal, so lees die ry vir die kanaal wat jy bedoel eerder as die eerste een wat gelys word. Replica_IO_Running skei 'n gekoppelde ontvanger van een wat koppel of gestop is, en Replica_SQL_Running beskryf die toepasser. Lees die foutkolomme daarmee saam, want 'n ontvanger wat weer koppel en dadelik misluk, laat 'n boodskap wat geen statusvlag sal wys nie. Ouer weergawes gebruik ander kolomname, so moenie 'n ou resep vertaal deur net opdragte te hernoem nie.

Kontroleer ook die bron-identiteit en enige gekonfigureerde filters. 'n Replika wat na die verkeerde bron wys, of nouer gefiltreer as wat jy dink, rapporteer gesond terwyl dit iets anders repliseer as wat jy verwag.

Hoekom 'n nul-agterstand syfer kan lieg

Die agterstandwaarde vergelyk die tydstempel van die laaste toegepaste gebeurtenis met die huidige tyd. Wanneer die ontvanger vir 'n uur gestop was, kan die toepasser deur die agterstand werk en die einde bereik van wat dit ontvang het, op watter punt die syfer na nul val al is die replika 'n uur agter die bron. Die maatstaf meet die toepasser se tou, nie die replika se aktualiteit nie.

Vergelyk eerder uitgevoerde transaksies met wat die bron beskikbaar het. Daardie vergelyking oorleef 'n gestopte ontvanger.

Bewaring bepaal die werklike herstelvenster

Om in te haal vereis dat die bron steeds die transaksies hou wat die replika nodig het. Sodra dit uitgevee is, kan die replika dit nie haal nie, en geen hoeveelheid herkoppeling verander dit nie.

Met GTID-outoposisie is die mislukking eksplisiet: die replika vra vir geskiedenis wat die bron nie meer hou nie en weier om voort te gaan. Die opsies is dan om die ontbrekende gebeure by 'n bron te kry wat dit nog het, of om uit 'n rugsteun te herbou en dit te laat inhaal. Om die gaping oor te slaan is nie inhaal nie, en dit laat 'n replika wie se data stilswyend onvolledig is. Beplan die venster deur verwagte onderbrekingsduur te vergelyk met binêrelog-bewaring op die bron en die veranderingstempo, want daardie drie syfers besluit of 'n onderbreking hoegenaamd herstelbaar is.

Verifieer inhaal, nie die kleur van 'n aanwyser nie

Herstel die pad, insluitend naamresolusie en vervoersekuriteit, en kyk dan of die bestaande kanaal volgens sy eie beleid weer koppel. Gee dit 'n bepaalde interval voordat jy ingryp, en teken ontvangs- en toepassingsvordering aan by beide kante van daardie interval. 'n Kanaal wat herbegin en 'n kanaal wat op datum is, is verskillende bevindings.

Bevestig dat die toepasser die bron se huidige posisie bereik het, nie net die einde van die ou agterstand nie. Kyk dat geen fout in die toepasser wag nie, want een mislukte gebeurtenis stop vordering terwyl die ontvanger aanhou rapporteer dat dit gekoppel is. Teken dan die bewyse aan: kanaalnaam, beide stadiumtoestande, die uitgevoerde posisie en die tyd. 'n Groen aanwyser is 'n bewering; die posisie is 'n feit.

Verwante artikels