sql >> Databáze >  >> RDS >> MariaDB

Vysoce dostupné komponenty databáze (HA) prostřednictvím Load Balancers

Výběr topologie HA

Existují různé způsoby, jak udržet vysokou dostupnost s databázemi. Můžete použít virtuální IP adresy (VRRP) ke správě dostupnosti hostitele, můžete použít správce zdrojů, jako je Zookeeper a Etcd, k (re)konfiguraci vašich aplikací nebo použít nástroje pro vyrovnávání zatížení/proxy k rozložení zátěže na všechny dostupné hostitele.

Virtuální IP adresy potřebují buď aplikaci pro jejich správu (MHA, Orchestrator), nějaké skriptování (Keepalived, Pacemaker/Corosync) nebo inženýra pro ruční převzetí služeb při selhání a rozhodování v tomto procesu může být složité. Přepnutí při selhání virtuální IP je přímočarý a jednoduchý proces odebráním IP adresy z jednoho hostitele, přiřazením k jinému hostiteli a pomocí arpingu k odeslání bezdůvodné odpovědi ARP. Teoreticky lze virtuální IP přesunout během sekundy, ale bude trvat několik sekund, než si aplikace pro správu převzetí služeb při selhání bude jistá, že hostitel selhal, a bude podle toho jednat. Ve skutečnosti by to mělo být někde mezi 10 a 30 sekundami. Dalším omezením virtuálních IP adres je, že někteří poskytovatelé cloudu neumožňují spravovat vlastní virtuální IP adresy nebo je vůbec přidělovat. Např. Google vám to na svých výpočetních uzlech neumožňuje.

Správci zdrojů, jako jsou Zookeeper a Etcd, mohou monitorovat vaše databáze a (re)konfigurovat vaše aplikace, jakmile hostitel selže nebo když je slave povýšen na master. Obecně je to dobrý nápad, ale implementace vašich kontrol pomocí Zookeeper a Etcd je složitý úkol.

Nástroj pro vyrovnávání zatížení nebo proxy bude sedět mezi aplikací a hostitelem databáze a bude fungovat transparentně, jako by se klient připojoval přímo k hostiteli databáze. Stejně jako v případě virtuálních IP a správců zdrojů potřebují vyvažovači zatížení a proxy také monitorovat hostitele a přesměrovat provoz, pokud je jeden hostitel mimo provoz. ClusterControl podporuje dva proxy:HAProxy a ProxySQL a oba jsou podporovány pro replikaci MySQL master-slave a cluster Galera. HAProxy i ProxySQL mají své vlastní případy použití, popíšeme je také v tomto příspěvku.

Proč potřebujete Load Balancer?

Teoreticky nepotřebujete load balancer, ale v praxi jej budete preferovat. Vysvětlíme proč.

Pokud máte nastavené virtuální IP adresy, vše, co musíte udělat, je nasměrovat vaši aplikaci na správnou (virtuální) IP adresu a vše by mělo být v pořádku. Předpokládejme však, že jste zvýšili počet čtených replik, možná budete chtít poskytnout virtuální IP adresy pro každou z těchto čtených replik také z důvodu údržby nebo dostupnosti. To se může stát velmi velkým fondem virtuálních IP adres, které musíte spravovat. Pokud jedna z těchto čtených replik selhala, musíte znovu přiřadit virtuální IP jinému hostiteli, jinak se vaše aplikace připojí buď k hostiteli, který je mimo provoz, nebo v nejhorším případě ke zpožděnému serveru se zastaralými daty. Proto je nutné udržovat stav replikace na aplikaci spravující virtuální IP adresy.

Také pro Galera existuje podobná výzva:teoreticky můžete do konfigurace aplikace přidat tolik hostitelů, kolik chcete, a náhodně vybrat jednoho. Stejný problém nastává, když je tento hostitel mimo provoz:může se stát, že se připojíte k nedostupnému hostiteli. Také použití všech hostitelů pro čtení i zápis může také způsobit vrácení zpět kvůli optimistickému zamykání v Galeře. Pokud se dvě připojení pokusí zapsat do stejného řádku současně, jedno z nich obdrží vrácení zpět. V případě, že vaše pracovní vytížení má takové souběžné aktualizace, doporučuje se používat pro zápis pouze jeden uzel v Galeře. Proto chcete správce, který sleduje vnitřní stav vašeho databázového clusteru.

HAProxy i ProxySQL vám nabídnou funkcionalitu pro monitorování hostitelů databáze MySQL/MariaDB a udržování stavu vašeho clusteru a jeho topologie. Pro nastavení replikace platí, že v případě, že je podřízená replika mimo provoz, HAProxy i ProxySQL mohou redistribuovat připojení k jinému hostiteli. Ale pokud je hlavní replikační server mimo provoz, HAProxy odmítne připojení a ProxySQL vrátí klientovi správnou chybu. U nastavení Galera mohou oba nástroje pro vyrovnávání zatížení zvolit hlavní uzel z clusteru Galera a odeslat operace zápisu pouze do tohoto konkrétního uzlu.

Na první pohled se může zdát, že HAProxy a ProxySQL jsou podobná řešení, ale velmi se liší ve funkcích a způsobu distribuce připojení a dotazů. HAProxy podporuje řadu vyvažovacích algoritmů, jako je nejmenší připojení, zdroj, náhodný a kruhový, zatímco ProxySQL distribuuje připojení pomocí algoritmu kruhového vyvažování založeného na váze (stejná váha znamená stejné rozložení). Vzhledem k tomu, že ProxySQL je inteligentní proxy, zná databázi a je také schopen analyzovat vaše dotazy. ProxySQL je schopen provádět rozdělení čtení/zápisu na základě pravidel dotazů, kde můžete dotazy přeposílat určeným podřízeným nebo hlavním ve vašem clusteru. ProxySQL obsahuje další funkce, jako je přepisování dotazů, ukládání do mezipaměti a firewall dotazů s generováním hloubkových statistik o pracovní zátěži v reálném čase.

To by mělo stačit na pozadí tohoto tématu, takže se podívejme, jak můžete nasadit oba nástroje pro vyrovnávání zatížení pro replikaci MySQL a topologie Galera.

Nasazení HAProxy

Použití ClusterControl k nasazení HAProxy na cluster Galera je snadné:přejděte do příslušného clusteru a vyberte „Add Load Balancer“:

A budete moci nasadit instanci HAProxy přidáním adresy hostitele a výběrem instancí serveru, které chcete zahrnout do konfigurace:

Ve výchozím nastavení bude instance HAProxy nakonfigurována tak, aby odesílala připojení k instancím serveru, které přijímají nejmenší počet připojení, ale tuto zásadu můžete změnit na kruhovou nebo zdrojovou.

V pokročilých nastaveních můžete nastavit časové limity, maximální počet připojení a dokonce zabezpečit proxy přidáním rozsahu IP pro připojení.

Na kartě uzly tohoto clusteru se zobrazí uzel HAProxy:

Nyní je váš cluster Galera dostupný také prostřednictvím nově nasazeného uzlu HAProxy na portu 3307. Nezapomeňte své aplikaci UDĚLIT přístup z IP adresy HAProxy, protože nyní bude provoz přicházet z proxy namísto hostitelů aplikace. Nezapomeňte také nasměrovat připojení aplikace na uzel HAProxy.

Nyní předpokládejme, že by došlo k výpadku jedné instance serveru, HAProxy si toho všimne během několika sekund a zastaví odesílání provozu do této instance:

Dva další uzly jsou stále v pořádku a budou nadále přijímat provoz. Díky tomu je cluster vysoce dostupný, aniž by si klient všiml rozdílu.

Nasazení sekundárního uzlu HAProxy

Nyní, když jsme přesunuli odpovědnost za zachování vysoké dostupnosti přes databázová připojení z klienta na HAProxy, co když uzel proxy zemře? Odpověď je vytvořit další instanci HAProxy a použít virtuální IP řízenou Keepalived, jak je znázorněno na tomto diagramu:

Výhodou ve srovnání s používáním virtuálních IP adres na databázových uzlech je, že logika pro MySQL je na úrovni proxy a převzetí služeb při selhání pro proxy je jednoduché.

Pojďme tedy nasadit sekundární uzel HAProxy:

Poté, co jsme nasadili sekundární uzel HAProxy, musíme přidat Keepalived:

A po přidání Keepalived bude váš přehled uzlů vypadat takto:

Takže nyní místo přímého nasměrování připojení aplikací na uzel HAProxy je musíte místo toho nasměrovat na virtuální IP.

V tomto příkladu jsme ke spuštění HAProxy použili samostatné hostitele, ale můžete je snadno přidat i do existujících serverových instancí. HAProxy nepřináší mnoho režií, i když byste měli mít na paměti, že v případě selhání serveru ztratíte databázový uzel i proxy.

Nasazení ProxySQL

Nasazení ProxySQL do vašeho clusteru se provádí podobným způsobem jako HAProxy:"Add Load Balancer" v seznamu clusterů na kartě ProxySQL.

V průvodci nasazením určete, kam se bude ProxySQL instalovat, administrátora/heslo, monitorovacího uživatele/heslo pro připojení k backendům MySQL. Z ClusterControl můžete buď vytvořit nového uživatele, kterého bude aplikace používat (uživatel bude vytvořen na MySQL i ProxySQL), nebo použít stávající uživatele databáze (uživatel bude vytvořen pouze na ProxySQL). Nastavte, zda používáte implicitní transakce nebo ne. V zásadě, pokud k vytvoření nové transakce nepoužijete SET autocommit=0, ClusterControl nakonfiguruje rozdělení čtení/zápisu.

Po nasazení ProxySQL bude k dispozici na kartě Nodes:

Otevřením přehledu uzlů ProxySQL se vám zobrazí rozhraní pro monitorování a správu ProxySQL, takže již není důvod se přihlašovat do ProxySQL na uzlu. ClusterControl pokrývá většinu důležitých statistik ProxySQL, jako je využití paměti, mezipaměť dotazů, procesor dotazů atd., stejně jako další metriky, jako jsou skupiny hostitelů, servery typu backend, hity pravidel dotazu, hlavní dotazy a proměnné ProxySQL. V aspektu správy ProxySQL můžete spravovat pravidla dotazů, backendové servery, uživatele, konfiguraci a plánovač přímo z uživatelského rozhraní.

Podívejte se na naši stránku s výukovým programem ProxySQL, která obsáhle popisuje, jak provádět vyrovnávání zatížení databáze pro MySQL a MariaDB pomocí ProxySQL.

Nasazení Garbd

Galera implementuje algoritmus založený na kvoru pro výběr primární komponenty, jejímž prostřednictvím vynucuje konzistenci. Primární složka potřebuje mít většinu hlasů (50 % + 1 uzel), takže v systému 2 uzlů by nedocházelo k žádné většině, což by vedlo k rozdělení mozku. Naštěstí je možné přidat garbd (Galera Arbitrator Daemon), což je lehký bezstavový démon, který může fungovat jako lichý uzel. Další výhodou přidáním Galera Arbitrator je to, že nyní můžete pracovat pouze se dvěma uzly ve vašem clusteru.

Pokud ClusterControl zjistí, že se váš cluster Galera skládá ze sudého počtu uzlů, dostanete od ClusterControl varování/radu, abyste rozšířili cluster na lichý počet uzlů:

Vyberte si moudře hostitele, na který chcete nasadit garbd, protože bude přijímat všechna replikovaná data. Ujistěte se, že síť zvládne provoz a je dostatečně bezpečná. Můžete si vybrat jednoho z hostitelů HAProxy nebo ProxySQL k nasazení garbd, jako v příkladu níže:

Vezměte na vědomí, že počínaje ClusterControl 1.5.1 nelze garbd nainstalovat na stejný hostitel jako ClusterControl kvůli riziku konfliktů balíčků.

Po instalaci garbd uvidíte, že se objeví vedle vašich dvou uzlů Galera:

Poslední myšlenky

Ukázali jsme vám, jak udělat vaše MySQL master-slave a nastavení clusteru Galera robustnější a zachovat vysokou dostupnost pomocí HAProxy a ProxySQL. Také garbd je pěkný démon, který dokáže uložit další třetí uzel ve vašem clusteru Galera.

Tím je dokončena strana nasazení ClusterControl. V našem příštím blogu vám ukážeme, jak integrovat ClusterControl do vaší organizace pomocí skupin a přiřazení určitých rolí uživatelům.


  1. Nelze načíst DLL „OraOps10.dll“

  2. Závažná chyba PHP:Třída 'PDO' nebyla nalezena

  3. SQL Server kontingenční tabulka s více sloupcovými agregacemi

  4. Příběh dvou shluků faktorů