Automatizované převzetí služeb při selhání je v podstatě nutností pro mnoho aplikací – doba provozuschopnosti je považována za samozřejmost. Je docela těžké přijmout, že aplikace je mimo provoz na 20 nebo 30 minut, protože někdo musí být odvolán, aby se přihlásil a prošetřil situaci, než zasáhne.
V reálném světě se nastavení replikace postupem času rozrůstají a stávají se složitými a někdy chaotickými. A existují omezení. Například ne každý uzel v nastavení je dobrým hlavním kandidátem. Možná se hardware liší a některé repliky mají méně výkonný hardware, protože jsou určeny ke zpracování některých specifických typů zátěže? Možná jste uprostřed migrace na novou verzi MySQL a některé z slave již byly upgradovány? Raději byste neměli mít předlohu v novější verzi replikující se do starých replik, protože to může přerušit replikaci. Máte-li dvě datová centra, jedno aktivní a jedno pro zotavení po havárii, možná budete chtít vybrat hlavní kandidáty pouze v aktivním datovém centru, aby bylo hlavní zařízení blízko hostitelům aplikace. To jsou jen příklady situací, kdy se můžete ocitnout v případě potřeby ručního zásahu během procesu převzetí služeb při selhání. Naštěstí mnoho nástrojů pro převzetí služeb při selhání má možnost převzít kontrolu nad procesem pomocí bílých a černých listin. V tomto příspěvku na blogu bychom vám rádi ukázali několik příkladů, jak můžete ovlivnit algoritmus ClusterControl pro výběr hlavních kandidátů.
Konfigurace bílé a černé listiny
ClusterControl vám dává možnost definovat jak whitelist, tak blacklist replik. Whitelist je seznam replik, které se mají stát hlavními kandidáty. Pokud žádná z nich není k dispozici (buď proto, že jsou mimo provoz, nebo existují chybné transakce nebo existují jiné překážky, které brání povýšení kterékoli z nich), převzetí služeb při selhání se neprovede. Tímto způsobem můžete definovat, kteří hostitelé jsou k dispozici, aby se stali hlavním kandidátem. Na druhé straně černé listiny definují, které repliky nejsou vhodné k tomu, aby se staly hlavním kandidátem.
Oba tyto seznamy lze definovat v konfiguračním souboru cmon pro daný cluster. Pokud má váš cluster například id ‚1‘, chcete upravit ‚/etc/cmon.d/cmon_1.cnf‘. Pro whitelist použijete proměnnou ‚replication_failover_whitelist‘, pro blacklist to bude ‚replication_failover_blacklist‘. Oba akceptují čárkami oddělený seznam ‚host:port‘.
Podívejme se na následující nastavení replikace. Máme aktivní master (10.0.0.141), který má dvě repliky (10.0.0.142 a 10.0.0.143), oba fungují jako střední master a každý má jednu repliku (10.0.0.144 a 10.0.0.147). Máme také záložní master v samostatném datovém centru (10.0.0.145), které má repliku (10.0.0.146). Tyto hostitele jsou určeny k použití v případě katastrofy. Repliky 10.0.0.146 a 10.0.0.147 fungují jako záložní hostitelé. Viz níže uvedený snímek obrazovky.
Vzhledem k tomu, že druhé datové centrum je určeno pouze pro obnovu po havárii, nechceme, aby žádný z těchto hostitelů byl povýšen jako hlavní. V nejhorším případě provedeme ruční zásah. Infrastruktura druhého datového centra není přizpůsobena velikosti produkčního datového centra (v datovém centru DR je o tři repliky méně), takže předtím, než budeme moci propagovat hostitele v datovém centru DR, jsou stejně potřeba ruční zásahy. Také bychom nechtěli, aby byla propagována záložní replika (10.0.0.147). Ani my nechceme, aby třetí replika v řetězci byla vyzvednuta jako hlavní (i když by to šlo udělat s GTID).
Konfigurace seznamu povolených
Můžeme nakonfigurovat buď whitelist, nebo blacklist, abychom zajistili, že převzetí služeb při selhání bude řešeno podle našich představ. V tomto konkrétním nastavení může být použití whitelistu vhodnější - definujeme, které hostitele lze použít pro převzetí služeb při selhání, a pokud někdo přidá nového hostitele do nastavení, nebude považován za hlavního kandidáta, dokud někdo ručně nerozhodne, že je to nutné. dobře ji použít a přidat na bílou listinu. Pokud bychom použili blacklist, přidání nové repliky někde v řetězci by mohlo znamenat, že taková replika by mohla být teoreticky automaticky použita pro převzetí služeb při selhání, pokud někdo výslovně neřekne, že ji nelze použít. Zůstaňme na bezpečné straně a definujme whitelist v našem konfiguračním souboru clusteru (v tomto případě je to /etc/cmon.d/cmon_1.cnf, protože máme pouze jeden cluster):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Musíme se ujistit, že proces cmon byl restartován, aby se změny uplatnily:
service cmon restartPředpokládejme, že náš master havaroval a ClusterControl jej nemůže dosáhnout. Bude zahájena úloha převzetí služeb při selhání:
Topologie bude vypadat takto:
Jak vidíte, starý master je deaktivován a ClusterControl se ho nepokusí automaticky obnovit. Je na uživateli, aby zkontroloval, co se stalo, zkopíroval všechna data, která nemusela být replikována do hlavního kandidáta, a znovu sestavil starý vzor:
Pak je to otázka několika změn topologie a můžeme topologii uvést do původního stavu, stačí nahradit 10.0.0.141 10.0.0.142:
Konfigurace černé listiny
Nyní se podíváme, jak funguje blacklist. Zmínili jsme, že v našem příkladu to nemusí být nejlepší možnost, ale pro ilustraci to zkusíme. Umístíme na černou listinu každého hostitele kromě 10.0.0.141, 10.0.0.142 a 10.0.0.143, protože to jsou hostitelé, které chceme vidět jako hlavní kandidáty.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Také restartujeme proces cmon, abychom použili změny konfigurace:
service cmon restartProces převzetí služeb při selhání je podobný. Opět, jakmile je detekována hlavní chyba, ClusterControl spustí úlohu převzetí služeb při selhání.
Když replika nemusí být dobrým hlavním kandidátem
V této krátké části bychom rádi probrali podrobněji některé případy, kdy možná nebudete chtít povýšit danou repliku na novou předlohu. Doufejme, že vám to poskytne představu o případech, kdy možná budete muset zvážit vyvolání větší ruční kontroly procesu převzetí služeb při selhání.
Různá verze MySQL
Za prvé, pokud vaše replika používá jinou verzi MySQL než hlavní, není dobrý nápad ji propagovat. Obecně řečeno, novější verze je vždy neaktivní, protože replikace z nové na starou verzi MySQL není podporována a nemusí fungovat správně. To se týká většinou hlavních verzí (například 8.0 replikující se na 5.7), ale osvědčeným postupem je se tomuto nastavení úplně vyhnout, i když mluvíme o malých rozdílech mezi verzemi (5.7.x+1 -> 5.7.x). Replikace z nižší na vyšší/novější verzi je podporována, protože je pro proces upgradu nutností, ale přesto byste se tomu raději chtěli vyhnout (pokud je například váš master na 5.7.x+1, raději ho nenahrazujete s replikou na 5.7.x).
Různé role
Svým replikám můžete přiřadit různé role. Můžete si vybrat jednu z nich, aby byla k dispozici vývojářům k testování jejich dotazů na produkční datové sadě. Jeden z nich můžete použít pro pracovní zátěž OLAP. Jeden z nich můžete použít pro zálohování. Bez ohledu na to, co to je, obvykle byste nechtěli povýšit takovou repliku na master. Všechny tyto dodatečné, nestandardní úlohy mohou způsobit problémy s výkonem kvůli dodatečné režii. Dobrou volbou pro hlavního kandidáta je replika, která zvládá „normální“ zátěž, víceméně stejný typ zátěže jako aktuální master. Pak si můžete být jisti, že zvládne hlavní zatížení po převzetí služeb při selhání, pokud je zpracovávalo před tím.
Různé hardwarové specifikace
Zmínili jsme různé role pro repliky. Není neobvyklé vidět také různé hardwarové specifikace, zejména ve spojení s různými rolemi. Například záložní slave s největší pravděpodobností nemusí být tak výkonný jako běžná replika. Vývojáři mohou také testovat své dotazy na pomalejší databázi, než je produkční (většinou proto, že byste neočekávali stejnou úroveň souběžnosti u vývojové a produkční databáze) a lze například snížit počet jader CPU. Velikost nastavení obnovy po havárii může být také zmenšena, pokud by jejich hlavní úlohou bylo držet krok s replikací a očekává se, že nastavení DR bude muset být škálováno (jak vertikálně, velikostí instance, tak horizontálně, přidáním dalších replik) než na něj bude možné přesměrovat provoz.
Zpožděné repliky
Některé repliky mohou být zpožděny – je to velmi dobrý způsob, jak zkrátit dobu obnovy v případě ztráty dat, ale dělá z nich velmi špatné hlavní kandidáty. Pokud se replika zpozdí o 30 minut, o těchto 30 minut transakcí buď přijdete, nebo budete muset počkat (pravděpodobně ne 30 minut, protože replika to s největší pravděpodobností dokáže dohnat rychleji), než replika použije všechny zpožděné transakce. ClusterControl vám umožňuje vybrat, zda chcete počkat, nebo chcete přepnout na selhání okamžitě, ale fungovalo by to dobře s velmi malým zpožděním – maximálně desítky sekund. Pokud má převzetí služeb při selhání trvat minuty, nemá smysl takovou repliku používat, a proto je dobré ji umístit na černou listinu.
Různá datová centra
Zmínili jsme zmenšená nastavení DR, ale i když je vaše druhé datové centrum přizpůsobeno velikosti produkce, stále může být dobrý nápad ponechat převzetí služeb při selhání pouze v rámci jednoho DC. Pro začátek mohou být vaši aktivní hostitelé aplikací umístěni v hlavním datovém centru, takže přesun hlavního serveru do záložního DC by výrazně zvýšil latenci pro dotazy na zápis. V případě rozdělení sítě možná budete chtít tuto situaci vyřešit ručně. MySQL nemá vestavěný mechanismus kvora, a proto je trochu složité správně (automaticky) zvládnout ztrátu sítě mezi dvěma datovými centry.