V části I jsme představili rámec High Availability (HA) pro hosting MySQL a probrali různé komponenty a jejich funkčnost. Nyní v části II probereme podrobnosti semisynchronní replikace MySQL a související konfigurační nastavení, která nám pomáhají zajistit redundanci a konzistenci dat v našem nastavení HA. Nezapomeňte se vrátit do části III, kde zkontrolujeme různé scénáře selhání, které by mohly nastat, a způsob, jakým framework reaguje a zotavuje se z těchto podmínek.
Co je semisynchronní replikace MySQL?
Zjednodušeně řečeno, v konfiguraci semisynchronní replikace MySQL master odevzdá transakce do úložiště až poté, co obdrží potvrzení od alespoň jednoho z podřízených. Podřízené jednotky by mohly potvrdit potvrzení až poté, co jsou události přijaty a zkopírovány do protokolů relé a také vyprázdněny na disk. To zaručuje, že pro všechny transakce zaslané a vrácené klientovi existují data alespoň na 2 uzlech. Termín „semi“ v semisynchronní (replikaci) je důsledkem skutečnosti, že hlavní zařízení potvrdí transakce, jakmile jsou události přijaty a vyprázdněny do protokolu přenosu, ale nemusí se nutně odevzdat datovým souborům na podřízeném zařízení. To je na rozdíl od plně synchronní replikace, kde by transakce byla potvrzena jak na podřízeném, tak na hlavním serveru, než se relace vrátí klientovi.
Semisynchronní replikace, která je nativně dostupná v MySQL, pomáhá frameworku HA zajistit konzistenci dat a redundanci pro potvrzené transakce. V případě selhání masteru by byly všechny transakce provedené na masteru replikovány alespoň do jednoho z podřízených (uložených do protokolů přenosu). V důsledku toho by bylo převzetí služeb při selhání tohoto slave zařízení bezeztrátové, protože slave zařízení je aktuální (po úplném vybití reléových protokolů slave).
Replikace a semisynchronní související nastavení
Pojďme diskutovat o některých klíčových nastaveních MySQL používaných k zajištění optimálního chování pro vysokou dostupnost a konzistenci dat v našem rámci.
Správa rychlosti provádění otroků
První úvahou je zvládnout „polo“ chování semisynchronní replikace, která pouze zaručuje, že data byla přijata a vyprázdněna do protokolů přenosu I/O vláknem slave, ale nemusí být nutně potvrzena vláknem SQL. Ve výchozím nastavení je SQL vlákno v MySQL slave jednovláknové a nebude schopno držet krok s hlavním, který je vícevláknový. Zřejmý dopad toho je, že v případě selhání hlavní jednotky nebude podřízená jednotka aktuální, protože její vlákno SQL stále zpracovává události v protokolu přenosu. To zpozdí proces převzetí služeb při selhání, protože náš rámec očekává, že slave bude plně aktuální, než bude moci být povýšen. To je nezbytné pro zachování konzistence dat. Abychom tento problém vyřešili, povolili jsme vícevláknové podřízené jednotky pomocí možnosti slave_parallel_workers pro nastavení počtu paralelních vláken SQL pro zpracování událostí v protokolech přenosu.
Kromě toho nakonfigurujeme níže uvedená nastavení, která zajistí, že slave nepřejde do žádného stavu, ve kterém nebyl master:
- slave-parallel-type =LOGICKÉ_HODINY
- slave_preserve_commit_order =1
To nám poskytuje silnější konzistenci dat. S tímto nastavením budeme moci dosáhnout lepší paralelizace a rychlosti na podřízeném zařízení, ale pokud bude paralelních vláken příliš mnoho, zvýší se také režie spojená s koordinací mezi vlákny a může to bohužel kompenzovat výhody.
Další konfigurací, kterou můžeme použít ke zvýšení efektivity paralelního spouštění na podřízených zařízeních, je vyladění binlog_group_commit_sync_delay na masteru. Když toto nastavíte na master, binární položky protokolu na master, a tedy položky protokolu přenosu na slave budou mít dávky transakcí, které mohou být paralelně zpracovány vlákny SQL. To je podrobně vysvětleno na blogu J-F Gagného, kde toto chování nazývá „zpomalením pána, aby se zrychlil otrok“ .
Pokud své nasazení MySQL spravujete prostřednictvím konzole ScaleGrid, máte možnost nepřetržitě monitorovat a přijímat upozornění v reálném čase na zpoždění replikace podřízených zařízení. Umožňuje vám také dynamicky ladit výše uvedené parametry, abyste zajistili, že podřízené jednotky budou pracovat ruku v ruce s nadřízeným zařízením, čímž se minimalizuje váš čas spojený s procesem převzetí služeb při selhání.
Vysvětlení rámce MySQL High Availability Framework – část IIClick To Tweet
Důležité možnosti semisynchronní replikace
Semisynchronní replikace MySQL může podle návrhu přejít zpět do asynchronního režimu na základě nastavení časového limitu potvrzení slave zařízení nebo na základě počtu semisynchronních podřízených zařízení dostupných v libovolném okamžiku. Asynchronní režim podle definice neposkytuje záruky, že potvrzené transakce budou replikovány do podřízeného zařízení, a proto by ztráta hlavního serveru vedla ke ztrátě dat, která nebyla replikována. Výchozím návrhem rámce ScaleGrid HA je zabránit návratu do asynchronního režimu. Pojďme se podívat na konfigurace, které toto chování ovlivňují.
-
rpl_semi_sync_master_wait_for_slave_count
Tato možnost se používá ke konfiguraci počtu podřízených jednotek, které musí odeslat potvrzení, než může semisynchronní master provést transakci. V konfiguraci se 3 uzly master-slave jsme toto nastavili na 1, takže máme vždy jistotu, že data jsou dostupná alespoň v jednom slave zařízení a zároveň se vyhneme jakémukoli dopadu na výkon spojeným s čekáním na potvrzení od obou slave.
-
rpl_semi_sync_master_timeout
Tato možnost se používá ke konfiguraci doby, po kterou semisynchronní master čeká na potvrzení od slave zařízení, než se přepne zpět do asynchronního režimu. Nastavili jsme to na relativně vysokou hodnotu časového limitu, takže nedochází k žádnému návratu do asynchronního režimu.
Protože pracujeme se 2 otroky a rpl_semi_sync_master_wait_for_slave_count je nastaveno na 1, všimli jsme si, že alespoň jeden z otroků v rozumném čase potvrdí a hlavní nepřepne do asynchronního režimu během dočasných výpadků sítě.
-
rpl_semi_sync_master_wait_no_slave
To řídí, zda master čeká na vypršení časového limitu nakonfigurovaného rpl_semi_sync_master_timeout, i když počet slave klesne na méně než počet slave nakonfigurovaných rpl_semi_sync_master_wait_for_slave_count během časového limitu. Zachováme výchozí hodnotu ON, aby se hlavní server nevrátil zpět k asynchronní replikaci.
Dopad ztráty všech semisynchronních otroků
Jak jsme viděli výše, náš rámec brání hlavnímu zařízení v přechodu na asynchronní replikaci, pokud všechny podřízené jednotky selžou nebo se z hlavní jednotky stanou nedostupnými. Přímý dopad je v tom, že se zápisy na hlavním serveru zablokují, což má dopad na dostupnost služby. To je v podstatě tak, jak to popisuje teorém CAP o omezeních jakéhokoli distribuovaného systému. Věta říká, že v přítomnosti síťového oddílu si budeme muset vybrat buď dostupnost, nebo konzistenci, ale ne obojí. Síťový oddíl lze v tomto případě považovat za slave MySQL odpojené od hlavního serveru, protože jsou buď mimo provoz, nebo jsou nedostupné.
Naším cílem konzistentnosti je zajistit, aby pro všechny potvrzené transakce byla data dostupná alespoň na 2 uzlech. V důsledku toho v takových případech rámec ScaleGrid HA upřednostňuje konzistenci před dostupností. Další zápisy nebudou od klientů přijímány, ačkoli hlavní server MySQL bude stále obsluhovat požadavky na čtení. Toto je vědomé rozhodnutí o návrhu, které jsme učinili jako výchozí chování, které je samozřejmě konfigurovatelné na základě požadavků aplikace.
Nezapomeňte se přihlásit k odběru blogu ScaleGrid, aby vám neunikla část III, kde probereme další scénáře selhání a možnosti obnovy rámce MySQL HA . Zůstaňte naladěni!!
