Cloud Disaster Recovery pro MariaDB a MySQL

MySQL má dlouhou tradici v geografické replikaci. Distribuce klastrů do vzdálených datových center snižuje účinky geografické latence tím, že posouvá data blíže k uživateli. Poskytuje také schopnost zotavení po havárii. Kvůli značným nákladům na duplikaci hardwaru na samostatném místě si to v minulosti nemohlo dovolit mnoho společností. Další náklady představují kvalifikovaný personál, který je schopen navrhnout, implementovat a udržovat sofistikované prostředí více datových center.

Díky revoluci automatizace Cloud a DevOps nebylo distribuované datové centrum nikdy dostupnější pro masy. Poskytovatelé cloudu rozšiřují rozsah služeb, které nabízejí za lepší cenu. Je možné budovat cross-cloudová hybridní prostředí s daty rozmístěnými po celém světě. Je možné vytvořit flexibilní a škálovatelné plány DR, aby se přiblížily široké škále scénářů narušení. V některých případech to může být pouze záloha uložená mimo pracoviště. V jiných případech to může být kopie 1:1 produkčního prostředí běžícího někde jinde.

V tomto blogu se podíváme na některé z těchto případů a budeme se zabývat běžnými scénáři.

Ukládání záloh do cloudu

Plán DR je obecný termín, který popisuje proces obnovy narušených IT systémů a dalších kritických aktiv, která organizace používá. Zálohování je primární metodou, jak toho dosáhnout. Když je záloha ve stejném datovém centru jako vaše produkční servery, riskujete, že v případě ztráty datového centra mohou být všechna data vymazána. Abyste tomu zabránili, měli byste mít zásadu vytvořit kopii v jiném fyzickém umístění. Stále je dobrým zvykem uchovávat zálohu na disku, aby se zkrátila doba potřebná k obnově. Ve většině případů budete primární zálohu uchovávat ve stejném datovém centru (abyste minimalizovali dobu obnovy), ale měli byste mít také zálohu, kterou lze použít k obnovení obchodních postupů, když je primární datové centrum mimo provoz.

ClusterControl umožňuje bezproblémovou integraci mezi vaším databázovým prostředím a cloudem. Poskytuje možnosti pro migraci dat do cloudu. Nabízíme plnou kombinaci záloh databází pro Amazon Web Services (AWS), Google Cloud Services nebo Microsoft Azure. Zálohy lze nyní spouštět, plánovat, stahovat a obnovovat přímo od vašeho zvoleného poskytovatele cloudu. Tato schopnost poskytuje zvýšenou redundanci, lepší možnosti obnovy po havárii a výhody z hlediska výkonu a úspory nákladů.

Prvním krokem k nastavení „zálohování při selhání datového centra“ je poskytnutí přihlašovacích údajů pro vašeho cloudového operátora. Zde si můžete vybrat z více prodejců. Pojďme se podívat na proces nastavený pro nejpopulárnějšího cloudového operátora – AWS.

Vše, co potřebujete, je ID klíče AWS a tajemství pro oblast, kam chcete zálohu uložit. Můžete to získat z konzoly AWS. Chcete-li jej získat, postupujte podle několika kroků.

1. Použijte e-mailovou adresu a heslo svého účtu AWS k přihlášení do konzoly pro správu AWS jako uživatel root účtu AWS.
2. Na stránce IAM Dashboard vyberte v navigační liště název svého účtu a poté vyberte Moje pověření zabezpečení .
3. Pokud se zobrazí varování o přístupu k bezpečnostním pověřením pro váš účet AWS, zvolte Pokračovat na Bezpečnostní pověření .
4. Rozbalte část Přístupové klíče (ID přístupového klíče a tajný přístupový klíč).
5. Vyberte Vytvořit nový přístupový klíč . Poté zvolte Stáhnout soubor klíče pro uložení ID přístupového klíče a tajného přístupového klíče do souboru ve vašem počítači. Po zavření dialogového okna nebudete moci tento tajný přístupový klíč znovu získat.

Když je vše nastaveno, můžete upravit plán zálohování a povolit možnost zálohování do cloudu. Chcete-li snížit provoz v síti, povolte kompresi dat. Díky tomu jsou zálohy menší a minimalizuje se čas potřebný pro nahrávání. Další dobrou praxí je šifrování zálohy. ClusterControl automaticky vytvoří klíč a použije jej, pokud se jej rozhodnete obnovit. Pokročilé zásady zálohování by měly mít různé doby uchování pro zálohy uložené na serverech ve stejném datovém centru a pro zálohy uložené v jiném fyzickém umístění. Měli byste nastavit delší dobu uchování pro cloudové zálohy a kratší dobu pro zálohy uložené v blízkosti produkčního prostředí, protože pravděpodobnost obnovení klesá s životností zálohy.

Rozšiřte svůj cluster pomocí asynchronní replikace

Galera s asynchronní replikací může být vynikajícím řešením pro vybudování aktivního uzlu DR ve vzdáleném datovém centru. Existuje několik dobrých důvodů pro připojení asynchronního slave zařízení ke clusteru Galera. Dlouhotrvající dotazy typu OLAP na uzlu Galera mohou zpomalit celý cluster. Díky možnosti použití zpoždění vás může zpožděná replikace zachránit před lidskými chybami, takže všechny tyto zlaté vstupy nebudou okamžitě aplikovány na váš záložní uzel.

V ClusterControl se rozšíření skupiny uzlů Galera pomocí asynchronní replikace provádí v průvodci jediné stránky. Musíte poskytnout potřebné informace o vašem budoucím nebo stávajícím podřízeném serveru. Slave bude nastaven ze stávající zálohy nebo z čerstvě streamovaného XtraBackup z masteru do slave.

Vyvažovače zátěže v multidatacentru

Vyrovnávání zátěže je klíčovou součástí vysoké dostupnosti databází MySQL a MariaDB. Nestačí mít cluster zahrnující více datových center. Stále potřebujete své služby, abyste k nim měli přístup. Selhání nástroje pro vyrovnávání zatížení, který je k dispozici v jednom datovém centru, způsobí, že celé vaše prostředí nebude dostupné.

Jednou z populárních metod, jak skrýt složitost databázové vrstvy před aplikací, je použití proxy. Proxy fungují jako vstupní bod do databází, sledují stav databázových uzlů a měly by vždy směrovat provoz pouze do uzlů, které jsou k dispozici. ClusterControl usnadňuje nasazení a konfiguraci několika různých technologií pro vyrovnávání zátěže pro MySQL a MariaDB, včetně ProxySQL, HAProxy, s grafickým rozhraním typu point-and-click.

Umožňuje také učinit tuto komponentu nadbytečnou přidáním keepalived nad ni. Abyste zabránili tomu, aby vaše nástroje pro vyrovnávání zátěže byly jediným bodem selhání, nastavte dvě identické (jednu aktivní a jednu v jiném DC jako pohotovostní režim) instance HAProxy, ProxySQL nebo MariaDB Maxscale a použijte Keepalived ke spuštění protokolu VRRP (Virtual Router Redundancy Protocol) mezi jim. VRRP poskytuje virtuální IP adresu aktivnímu load balanceru a v případě selhání přenese virtuální IP do pohotovostního HAProxy. Je to bezproblémové, protože dvě instance proxy nepotřebují žádný sdílený stav.

Samozřejmě je třeba zvážit mnoho věcí, aby byly vaše databáze imunní vůči selhání datového centra.
Správné plánování a automatizace zajistí, že to bude fungovat! Šťastné shlukování!