Použití clusteru Galera je skvělý způsob, jak vytvořit vysoce dostupné prostředí pro MySQL nebo MariaDB. Jedná se o sdílené klastrové prostředí, které lze škálovat i nad 12-15 uzlů. Galera má však určitá omezení. Svítí v prostředích s nízkou latencí, ai když jej lze použít přes WAN, výkon je omezen latencí sítě. Výkon Galery může být také ovlivněn, pokud se jeden z uzlů začne chovat nesprávně. Například nadměrné zatížení jednoho z uzlů jej může zpomalit, což má za následek pomalejší zpracování zápisů, což ovlivní všechny ostatní uzly v clusteru. Na druhou stranu je zcela nemožné provozovat firmu bez analýzy vašich dat. Taková analýza obvykle vyžaduje spouštění náročných dotazů, což je zcela odlišné od zátěže OLTP. V tomto příspěvku na blogu probereme snadný způsob spouštění analytických dotazů na data uložená v Galera Cluster pro MySQL nebo MariaDB tak, aby to neovlivnilo výkon základního clusteru.
Jak spustit analytické dotazy na Galera Cluster?
Jak jsme uvedli, spouštění dlouhodobých dotazů přímo na clusteru Galera je proveditelné, ale možná to není tak dobrý nápad. V závislosti na hardwaru to může být přijatelné řešení (pokud používáte silný hardware a nebudete provozovat vícevláknovou analytickou zátěž), ale i když využití CPU nebude problémem, skutečnost, že jeden z uzlů bude mít smíšenou zátěž ( OLTP a OLAP) budou samy o sobě představovat určité problémy s výkonem. Dotazy OLAP vyřadí data potřebná pro vaši pracovní zátěž OLTP z fondu vyrovnávacích pamětí, což zpomalí vaše dotazy OLTP. Naštěstí existuje jednoduchý, ale účinný způsob, jak oddělit analytickou zátěž od běžných dotazů – asynchronní replikační slave.
Replikační slave je velmi jednoduché řešení - vše, co potřebujete, je jen další hostitel, který může být zřízen a asynchronní replikace musí být konfigurována z Galera Cluster do tohoto uzlu. Při asynchronní replikaci slave žádným způsobem neovlivní zbytek klastru. Bez ohledu na to, zda je silně zatížen, používá jiný (méně výkonný) hardware, bude pokračovat v replikaci z jádra clusteru. Nejhorším scénářem je, že slave replikace začne zaostávat, ale pak je na vás, zda implementujete replikaci s více vlákny nebo případně škálujete slave replikaci.
Jakmile je replikační slave zařízení spuštěno a spuštěno, měli byste na něm spustit těžší dotazy a uvolnit cluster Galera. To lze provést několika způsoby v závislosti na vašem nastavení a prostředí. Pokud používáte ProxySQL, můžete snadno směrovat dotazy do analytického slave na základě zdrojového hostitele, uživatele, schématu nebo dokonce dotazu samotného. Jinak bude na vaší aplikaci, aby odeslala analytické dotazy správnému hostiteli.
Nastavení replikačního slave není příliš složité, ale stále může být složité, pokud nejste zběhlí v MySQL a nástrojích jako xtrabackup. Celý proces by spočíval v nastavení úložiště na novém serveru a instalaci databáze MySQL. Poté budete muset zřídit tohoto hostitele pomocí dat z clusteru Galera. K tomu můžete použít xtrabackup, ale další nástroje jako mydump/myloader nebo dokonce mysqldump budou fungovat také (pokud je spustíte správně). Jakmile budou data k dispozici, budete muset nastavit replikaci mezi hlavním uzlem Galera a podřízeným replikačním zařízením. Nakonec byste museli překonfigurovat vaši proxy vrstvu tak, aby zahrnovala novou podřízenou jednotku a směrovala provoz na ni nebo provést vylepšení v tom, jak se vaše aplikace připojuje k databázi, aby se část zátěže přesměrovala na replikační podřízenou jednotku.
Co je důležité mít na paměti, toto nastavení není odolné. Pokud by selhal „hlavní“ uzel Galera, replikační spojení bude přerušeno a bude provedena ruční akce k podřízení repliky jinému hlavnímu uzlu v clusteru Galera.
To není velký problém, zvláště pokud používáte replikaci s GTID (Global Transaction ID), ale musíte zjistit, že replikace je nefunkční, a poté provést ruční akci.
Jak nastavit asynchronní slave zařízení Galera Cluster pomocí ClusterControl?
Naštěstí, pokud používáte ClusterControl, lze celý proces automatizovat a vyžaduje jen několik kliknutí. Počáteční stav byl již nastaven pomocí ClusterControl – 3 uzlový cluster Galera se 2 uzly ProxySQL a 2 uzly Keepalived pro vysokou dostupnost databáze i proxy vrstvy.
Přidání podřízeného replikačního zařízení je vzdáleno pouhé kliknutí:
Replikace samozřejmě vyžaduje povolení binárních protokolů. Pokud nemáte povoleny binlogy na uzlech Galera, můžete to udělat také z ClusterControl. Mějte prosím na paměti, že povolení binárních protokolů bude vyžadovat restart uzlu, aby se změny konfigurace uplatnily.
I když má jeden uzel v clusteru povoleny binární protokoly (označené jako „Master“ na snímku obrazovky výše), stále je dobré povolit binární protokol na alespoň jednom dalším uzlu. ClusterControl může automaticky převzít selhání podřízeného replikačního zařízení poté, co zjistí, že hlavní uzel Galera havaroval, ale k tomu je vyžadován jiný hlavní uzel s povolenými binárními protokoly, jinak nebude mít nic, na co by mohl převzít.
Jak jsme uvedli, povolení binárních protokolů vyžaduje restart. Můžete to buď provést ihned, nebo jen provést změny konfigurace a restart provést jindy.
Po povolení binlogů na některých uzlech Galera můžete pokračovat v přidávání replikačního slave zařízení. V dialogovém okně musíte vybrat hlavního hostitele, předat název hostitele nebo IP adresu podřízeného. Pokud máte po ruce nedávné zálohy (což byste měli udělat), můžete jednu použít k vytvoření podřízeného zařízení. V opačném případě jej ClusterControl zajistí pomocí xtrabackup – všechna poslední hlavní data budou streamována do podřízeného zařízení a poté bude nakonfigurována replikace.
Po dokončení úlohy byla do klastru přidána podřízená replikace. Jak bylo uvedeno dříve, pokud 10.0.0.101 zemře, bude jako hlavní hostitel vybrán jiný hostitel v clusteru Galera a ClusterControl automaticky podřídí 10.0.0.104 jinému uzlu.
Protože používáme ProxySQL, musíme jej nakonfigurovat. Do ProxySQL přidáme nový server.
Vytvořili jsme další hostitelskou skupinu (30), kam jsme umístili našeho asynchronního otroka. Také jsme zvýšili „Max Replication Lag“ na 50 sekund z výchozích 10. Záleží na požadavcích vaší firmy, jak moc může analytický slave zaostávat, než se z toho stane problém.
Poté musíme nakonfigurovat pravidlo dotazu, které bude odpovídat našemu provozu OLAP a směrovat jej do hostitelské skupiny OLAP (30). Na snímku výše jsme vyplnili několik polí – toto není povinné. Obvykle budete muset použít jeden, maximálně dva z nich. Výše uvedený snímek obrazovky slouží jako příklad, takže můžeme snadno vidět, že můžete porovnat dotazy pomocí schématu (pokud máte samostatné schéma s analytickými daty), názvu hostitele/IP (pokud jsou dotazy OLAP prováděny z nějakého konkrétního hostitele), uživatele (pokud aplikace používá konkrétního uživatele pro analytické dotazy. Dotazy můžete také přímo porovnávat buď předáním úplného dotazu, nebo jejich označením komentáři SQL a nechat ProxySQL směrovat všechny dotazy s řetězcem „OLAP_QUERY“ do naší analytické hostitelské skupiny.
Jak můžete vidět, díky ClusterControl jsme byli schopni nasadit replikační slave do Galera Cluster pouhými několika kliknutími. Někdo může namítnout, že MySQL není nejvhodnější databází pro analytickou zátěž a my máme tendenci souhlasit. Toto nastavení můžete snadno rozšířit pomocí ClickHouse a nastavením replikace z asynchronního slave na sloupcové datové úložiště ClickHouse pro mnohem lepší výkon analytických dotazů. Toto nastavení jsme popsali v jednom z předchozích blogových příspěvků.