V nastavení MySQL 5.7 master-slave, které používá výchozí nastavení semisynchronní replikace pro rpl_semi_sync_master_wait_point , havárie master a failover na slave jsou považovány za bezztrátové. Když se však havarovaný hlavní server vrátí, můžete zjistit, že má transakce, které nejsou přítomny v aktuálním hlavním serveru (který byl dříve podřízeným). Toto chování může být matoucí, vzhledem k tomu, že semisynchronní replikace má být bezztrátová, ale ve skutečnosti jde o očekávané chování v MySQL. Proč přesně k tomu dochází, je podrobně vysvětleno v příspěvku na blogu Jeana-Françoise Gagného (JF).
S ohledem na takový scénář doporučuje dokumentace MySQL, že havarovaný hlavní server musí být zahozen a neměl by být restartován. Vyřazení takového serveru je však drahé a neefektivní. V tomto blogovém příspěvku vysvětlíme přístup k detekci a opravě transakcí na zhrouceném hlavním serveru MySQL v nastavení semisynchronní replikace a jak jej znovu přiřadit zpět do nastavení master-slave.
Proč je důležité zjišťovat další transakce na obnoveném vzoru?
Další transakce na obnoveném hlavním serveru se mohou projevit dvěma způsoby:
1. Selhání replikace MySQL, když je obnovený hlavní server znovu podřízen
To se obvykle stává, když máte primární klíč s automatickým přírůstkem. Když nový hlavní server MySQL vloží řádek do takové tabulky, replikace se nezdaří, protože klíč již na podřízeném zařízení existuje.
Dalším scénářem je situace, kdy se aplikace znovu pokusí o transakci, která selhala během hlavního selhání. Na obnoveném hlavním serveru MySQL (který je nyní slave) by tato transakce skutečně existovala a opět by to mělo za následek chybu replikace.
Chyba replikace MySQL by obvykle vypadala takto:
| [CHYBA] Slave SQL pro kanál '':Worker 5 selhal při provádění transakce 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' v hlavním protokolu mysql-bin.000030, end_log_pos 10262184; Chyba 'Duplicitní záznam '5018' pro klíč 'PRIMARY'' v dotazu. Výchozí databáze:'test'. Query:'insert into test values(5018,2019,'item100')', Error_code:1062 |
2. Tichá nekonzistence v datech mezi novým MySQL master a slave (obnoveným masterem)
V případech, kdy aplikace nezopakuje neúspěšnou transakci a v budoucnu nedojde ke kolizi primárního klíče, nemusí dojít k chybě replikace. V důsledku toho nemusí být nekonzistence dat odhalena.
V obou výše uvedených případech je ovlivněna buď vysoká dostupnost, nebo integrita dat vašeho nastavení MySQL, a proto je tak důležité tuto podmínku zjistit co nejdříve.
Jak zjistit další transakce na obnoveném MySQL Master
Můžeme zjistit, zda jsou na obnoveném hlavním serveru nějaké další transakce pomocí funkce MySQL GTID (global transaction identifier):
GTID_SUBSET(set1 ,set2 ):Jsou dány dvě sady globálních ID transakcí set1 a set2 , vrátí hodnotu true, pokud jsou všechna GTID v set1 jsou také v set2 . V opačném případě vrátí hodnotu false.
Použijme příklad, abychom to pochopili.
- GTID nastavené na obnoveném hlavním serveru, jehož UUID je:„54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ je:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810’
- Sada GTID nového hlavního serveru, jehož UUID je:„57956099-d01d-11e7-80bc-000d3af97c09 ’ je:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af-97ctt>9:
Nyní, když funkci GTID_SUBSET zavoláme jako GTID_SUBSET (sada GTID obnovené hlavní sady, sada GTID nové hlavní sady) , bude vrácená hodnota pravdivá, pouze pokud obnovený master nemá žádné další transakce. V našem příkladu výše, protože obnovený hlavní server má další transakce 9691 až 9700, je výsledek výše uvedeného dotazu nepravdivý.
Přeřazení havarovaného hlavního serveru #MySQL v nastavení semisynchronní replikace Kliknutím na TweetJak znovu otročit obnoveného MySQL Master, který má další transakce
Na základě výše uvedeného kroku je možné zjistit, zda má obnovený hlavní server další transakce a jaké tyto transakce používají funkci GTID:GTID_SUBTRACT(sada GTID obnovený master, sada GTID nového masteru).
Je také možné extrahovat tyto dodatečné transakce z binárních protokolů a uložit je. Pro váš obchodní tým může být užitečné tyto transakce později zkontrolovat, abyste se ujistili, že nedopatřením neztratíme žádné důležité obchodní informace, i když byly nevázány. Jakmile to uděláme, potřebujeme způsob, jak se těchto extra transakcí zbavit, aby mohl být obnovený hlavní server bez problémů znovu podřízen.
Jedním z nejjednodušších způsobů, jak toho dosáhnout, je pořídit záložní snímek aktuálního hlavního serveru a obnovit data na aktuálním podřízeném zařízení. Pamatujte, že musíte zachovat UUID tohoto serveru jako dříve. Po obnovení dat lze server znovu podřídit a zahájí replikaci od bodu obnoveného snímku. Brzy vám zase poběží zdravý otrok!
Výše uvedené kroky jsou velmi zdlouhavé, pokud je musíte provádět ručně, ale plně spravovaná hostingová služba MySQL společnosti ScaleGrid může celý proces zautomatizovat bez nutnosti jakéhokoli zásahu. Funguje to takto:
Pokud se váš aktuální hlavní server zhroutí, ScaleGrid automatizuje proces převzetí služeb při selhání a povýší vhodného podřízeného jako nového hlavního serveru. Poté je obnoven starý master a my automaticky zjistíme, zda na něm nejsou další transakce. Pokud se nějaké najdou, nasazení MySQL se uvede do degradovaného stavu a my použijeme automatizované nástroje k extrahování a uložení dalších transakcí pro vaši kontrolu. Náš tým podpory pak může obnovit starý hlavní server do dobrého stavu a znovu jej podřídit do vašeho nastavení master-slave, takže budete mít zdravé nasazení!
Chcete to zkusit? Začněte bezplatnou 30denní zkušební verzi a prozkoumejte všechny možnosti správy databází MySQL ve ScaleGrid.
