MySQL replikācija pēc VPN pārrāvuma: vispirms izlasiet abus posmus

Replikācijas uzraudzība kļūst sarkana, kad VPN atkrīt, un instinkts ir atiestatīt pozīciju. Tieši šis instinkts tīkla pārtraukumu pārvērš datu problēmā. Pārtraukts ceļš neko nepasaka par to, ko replika ir saņēmusi vai piemērojusi, un tie ir divi posmi ar diviem stāvokļiem. Izlasiet tos atsevišķi, pirms kaut ko maināt.

Divi posmi, divas atsevišķas atbildes

Parasta asinhrona replika veic divus darbus. Uztvērējs pieslēdzas avotam, velk notikumus un raksta tos lokāli pārsūtīšanas žurnālā. Piemērotājs lasa šo žurnālu un izpilda notikumus replikā. Kad ceļš pārtrūkst, uztvērējs apstājas uzreiz, bet piemērotājs turpina apstrādāt diska jau esošo atpalicību. Tāpēc viens pārtraukums rada divus dažādus jautājumus: vai savienojums ir atgriezies, un vai uzkrātais darbs ir piemērots? Uzskatot tos par vienu jautājumu, divi stāvokļi tiek vidēji aprēķināti maldinošā atbildē.

Uztvērēja atjaunošanās pasaka, ka ceļš darbojas. Tā nepasaka neko par to, cik tālu piemērotājs ir atpalicis, nedz arī to, vai tas saskārās ar kļūdu atvienotā stāvoklī.

Lasiet kanālu ar pareizo priekšrakstu

MySQL 8.4 versijā SHOW REPLICA STATUS atgriež vienu rindu katram konfigurētajam kanālam, tāpēc lasiet tā kanāla rindu, kuru domājat, nevis pirmo sarakstā. Replica_IO_Running atšķir pievienotu uztvērēju no tāda, kas pievienojas vai ir apturēts, un Replica_SQL_Running apraksta piemērotāju. Lasiet arī blakus esošās kļūdu kolonnas, jo uztvērējs, kas atkārtoti pievienojas un uzreiz neizdodas, atstāj ziņojumu, ko neparādīs neviens statusa karodziņš. Vecākas versijas izmanto citus kolonnu nosaukumus, tāpēc netulkojiet vecu recepti, tikai pārdēvējot komandas.

Pārbaudiet arī avota identitāti un visus konfigurētos filtrus. Replika, kas vērsta uz nepareizo avotu vai filtrēta šaurāk, nekā domājat, ziņo par veselību, kamēr replicē kaut ko citu, nekā gaidāt.

Kāpēc nulles aizture var melot

Aiztures vērtība salīdzina pēdējā piemērotā notikuma laika zīmi ar pašreizējo laiku. Kad uztvērējs ir bijis apturēts stundu, piemērotājs var apstrādāt atpalicību un sasniegt saņemtā beigas, un tad skaitlis nokrīt līdz nullei, lai gan replika atpaliek no avota par stundu. Metrika mēra piemērotāja rindu, nevis replikas aktualitāti.

Tā vietā salīdziniet izpildītos darījumus ar to, kas avotam ir pieejams. Šis salīdzinājums iztur iesprūdušu uztvērēju.

Īsto atjaunošanas logu nosaka glabāšana

Lai panāktu, avotam vēl jāglabā darījumi, kas replikai nepieciešami. Kad tie ir iztīrīti, replika tos nevar iegūt, un nekāda atkārtota pievienošanās to nemaina.

Ar GTID automātisko pozicionēšanu kļūme ir acīmredzama: replika pieprasa vēsturi, ko avots vairs neglabā, un atsakās turpināt. Tad iespējas ir iegūt trūkstošos notikumus no avota, kuram tie vēl ir, vai pārbūvēt no dublējuma un ļaut tam panākt. Spraugas izlaišana nav panākšana, un tā atstāj repliku, kuras dati klusi ir nepilnīgi. Plānojiet logu, salīdzinot gaidāmo pārtraukuma ilgumu ar binārā žurnāla glabāšanu avotā un izmaiņu tempu, jo šie trīs skaitļi izšķir, vai pārtraukumu vispār var atjaunot.

Pārbaudiet panākšanu, nevis indikatora krāsu

Atjaunojiet ceļu, tostarp nosaukumu izšķiršanu un transporta drošību, tad vērojiet, vai esošais kanāls atkārtoti pievienojas saskaņā ar savu politiku. Dodiet tam noteiktu intervālu pirms iejaukšanās un reģistrējiet saņemšanas un piemērošanas gaitu abos šī intervāla galos. Kanāls, kas restartējas, un kanāls, kas ir aktuāls, ir atšķirīgi atradumi.

Apstipriniet, ka piemērotājs ir sasniedzis pašreizējo avota pozīciju, nevis tikai vecās atpalicības beigas. Pārbaudiet, vai piemērotājā negaida kļūda, jo viens neizdevies notikums aptur gaitu, kamēr uztvērējs turpina ziņot par savienojumu. Pēc tam reģistrējiet pierādījumus: kanāla nosaukumu, abu posmu stāvokļus, izpildīto pozīciju un laiku. Zaļš indikators ir apgalvojums; pozīcija ir fakts.