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

Porovnání řešení selhání DBaaS s ručním nastavením obnovy

Nedávno jsme napsali několik blogů o tom, jak různí poskytovatelé cloudu řeší selhání databáze. Porovnali jsme výkon převzetí služeb při selhání v Amazon Aurora, Amazon RDS a ClusterControl, testovali jsme chování při selhání v Amazon RDS a také na Google Cloud Platform. I když tyto služby poskytují skvělé možnosti, pokud jde o převzetí služeb při selhání, nemusí být vhodné pro každou aplikaci.

V tomto příspěvku na blogu strávíme trochu času analýzou výhod a nevýhod používání řešení DBaaS ve srovnání s ručním návrhem prostředí nebo pomocí platformy pro správu databází, jako je ClusterControl.

Implementace databází s vysokou dostupností pomocí spravovaných řešení

Hlavním důvodem pro použití stávajících řešení je snadné použití. Můžete nasadit vysoce dostupné řešení s automatickým převzetím služeb při selhání během několika kliknutí. Není potřeba kombinovat různé nástroje dohromady, spravovat databáze ručně, nasazovat nástroje, psát skripty, navrhovat monitorování nebo jakékoli jiné operace správy databáze. Vše je již na svém místě. To může vážně snížit křivku učení a vyžaduje méně zkušeností k nastavení vysoce dostupného prostředí pro databáze; umožňuje v podstatě každému nasadit taková nastavení.

Ve většině případů s těmito řešeními je proces převzetí služeb při selhání proveden v přiměřené době. Může to být rychlé jako u Amazon Aurora nebo poněkud pomalejší jako u uzlů Google Cloud Platform SQL. Ve většině případů jsou tyto typy výsledků přijatelné.

Sečteno a podtrženo. Pokud dokážete přijmout 30–60 sekund prostoje, měli byste být v pořádku používat kteroukoli z platforem DBaaS.

Nevýhoda použití řízeného řešení pro HA

I když se řešení DBaaS snadno používají, mají také některé vážné nevýhody. Pro začátek je vždy třeba zvážit komponentu uzamčení dodavatele. Jakmile nasadíte cluster do Amazon Web Services, je docela složité migrovat od tohoto poskytovatele. Neexistují žádné snadné způsoby, jak stáhnout úplnou datovou sadu prostřednictvím fyzické zálohy. U většiny poskytovatelů jsou dostupné pouze ručně prováděné logické zálohy. Jistě, vždy existují možnosti, jak toho dosáhnout, ale obvykle se jedná o složitý, časově náročný proces, který přece jen může vyžadovat určité prostoje.

Použití poskytovatele, jako je Amazon RDS, také přináší omezení. Některé akce nelze snadno provést, což by bylo velmi jednoduché provést v prostředích nasazených plně řízeným způsobem uživatele (např. AWS EC2). Některá z těchto omezení již byla popsána v jiných blozích, ale abychom to shrnuli, žádná služba DBaaS vám neposkytuje stejnou úroveň flexibility jako běžná replikace založená na MySQL GTID. Můžete povýšit jakéhokoli otroka, můžete znovu zotročit každý uzel jiného... prakticky každá akce je možná. S nástroji jako RDS čelíte omezením způsobeným designem, která nemůžete obejít.

Problém je také se schopností porozumět detailům výkonu. Když navrhnete své vlastní vysoce dostupné nastavení, získáte informace o potenciálních problémech s výkonem, které se mohou objevit. Na druhou stranu RDS a podobná prostředí jsou v podstatě „černé skříňky“. Ano, dozvěděli jsme se, že Amazon RDS používá DRBD k vytvoření stínové kopie masteru, víme, že Aurora používá sdílené, replikované úložiště k implementaci velmi rychlých převzetí služeb při selhání. To je jen obecný poznatek. Nemůžeme říci, jaké jsou dopady na výkon těchto řešení, kromě toho, čeho bychom si mohli náhodně všimnout. Jaké jsou běžné problémy s nimi spojené? Jak stabilní jsou tato řešení? S jistotou to vědí pouze vývojáři za řešením.

Jaká je alternativa k řešení DBaaS?

Můžete se divit, existuje alternativa k DBaaS? Koneckonců, je tak pohodlné spouštět spravovanou službu, kde máte přístup k většině typických akcí prostřednictvím uživatelského rozhraní. Můžete vytvářet a obnovovat zálohy, převzetí služeb při selhání je řešeno automaticky za vás. Prostředí je snadno použitelné, což může být přesvědčivé pro společnosti, které nemají specializované a zkušené zaměstnance pro práci s databázemi.

ClusterControl poskytuje skvělou alternativu ke cloudovým službám DBaaS. Poskytuje vám grafické uživatelské rozhraní, které lze použít k nasazení, správě a monitorování databází s otevřeným zdrojovým kódem.

Během několika kliknutí můžete snadno nasadit vysoce dostupný databázový cluster s automatickým převzetím služeb při selhání (rychlejší než většina nabídek DBaaS), správou zálohování, pokročilým monitorováním a dalšími funkcemi, jako je integrace s externími nástroji (např. Slack nebo PagerDuty) nebo správu upgradu. To vše při úplném zamezení uzamčení prodejců.

ClusterControl se nestará o to, kde se vaše databáze nacházejí, pokud se k nim může připojit pomocí SSH. Nastavení můžete mít v cloudu, on-prem nebo ve smíšeném prostředí více poskytovatelů cloudu. Dokud bude konektivita existovat, bude ClusterControl schopen spravovat prostředí. Využití řešení, která chcete (a ne těch, která neznáte ani si jich neuvědomujete), vám umožní převzít plnou kontrolu nad prostředím v kterémkoli okamžiku.

Ať už jste s ClusterControl nasadili jakékoli nastavení, můžete jej snadno spravovat tradičnějším, ručním nebo skriptovaným způsobem. ClusterControl vám dokonce poskytuje rozhraní příkazového řádku, které vám umožní začlenit úlohy prováděné pomocí ClusterControl do vašich skriptů shellu. Máte veškerou kontrolu, kterou chcete – nic není černá skříňka, každý kousek prostředí by byl vytvořen pomocí řešení s otevřeným zdrojovým kódem kombinovaným dohromady a nasazeným ClusterControl.

Pojďme se podívat, jak snadno můžete nasadit cluster replikace MySQL pomocí ClusterControl. Předpokládejme, že máte připravené prostředí s nainstalovaným ClusterControl na jedné instanci a všechny ostatní uzly přístupné přes SSH z hostitele ClusterControl.

Začneme výběrem průvodce „Deploy“.

V prvním kroku musíme definovat, jak se má ClusterControl připojit k uzlům na které databáze mají být nasazeny. Podporován je přístup root i sudo (s heslem nebo bez něj).

Potom chceme vybrat dodavatele, verzi a předat heslo pro administrativního uživatele v naší databázi MySQL.

Nakonec chceme definovat topologii pro náš nový cluster. Jak vidíte, toto je již poměrně složité nastavení, na rozdíl od něčeho, co můžete nasadit pomocí uzlu AWS RDS nebo GCP SQL.

Vše, co nyní musíme udělat, je počkat na dokončení procesu. ClusterControl udělá vše pro to, aby porozuměl prostředí, do kterého nasazuje, a nainstaluje požadovanou sadu balíčků, včetně samotné databáze.

Jakmile je cluster zprovozněn, můžete pokračovat v nasazení proxy vrstva (která zajistí vaší aplikaci jediný vstupní bod do databázové vrstvy). To se víceméně děje v zákulisí DBaaS, kde máte také koncové body pro připojení k databázovému clusteru. Je docela běžné používat jeden koncový bod pro zápisy a více koncových bodů pro dosažení konkrétních replik.

Zde použijeme ProxySQL, který tu špinavou práci udělá za nás - bude rozumět topologii, zasílá zápisy pouze hlavnímu serveru a dotazy na vyvážení zátěže pouze pro čtení napříč všemi replikami, které máme.

Pro nasazení ProxySQL přejdeme do Spravovat -> Vyrovnávání zatížení.

Musíme vyplnit všechna povinná pole:hostitelé k nasazení, přihlašovací údaje pro administrativního a monitorovacího uživatele, můžeme importovat stávajícího uživatele z MySQL do ProxySQL nebo vytvořit nového. Všechny podrobnosti o ProxySQL lze snadno najít na několika blozích v naší blogové sekci.

Chceme, aby byly nasazeny alespoň dva uzly ProxySQL, aby byla zajištěna vysoká dostupnost. Poté, jakmile budou nasazeny, nasadíme Keepalived nad ProxySQL. To zajistí, že virtuální IP bude nakonfigurována a bude odkazovat na jednu z instancí ProxySQL, pokud bude existovat alespoň jeden zdravý uzel.

Zde je jediný potenciální problém, pokud používáte cloudová prostředí, kde funguje směrování způsobem, že nemůžete snadno vyvolat síťové rozhraní. V takovém případě budete muset upravit konfiguraci Keepalived, zavést skript 'notify_master' a použít skript, který provede potřebné změny IP - v případě EC2 by bylo nutné odpojit Elastic IP od jednoho hostitele a připojit jej k jiný hostitel.

Existuje spousta návodů, jak to udělat pomocí široce testovaného open source softwaru v nastaveních nasazených ClusterControl. Můžete snadno najít další informace, tipy a návody, které jsou relevantní pro vaše konkrétní prostředí.

Závěr

Doufáme, že jste našli tento blogový příspěvek srozumitelným. Pokud byste chtěli otestovat ClusterControl, přichází s 30denní podnikovou zkušební verzí, kde máte k dispozici všechny funkce. Můžete si jej zdarma stáhnout a vyzkoušet, zda se hodí do vašeho prostředí.


  1. Tabulky vs. databáze:Je čas přejít? Část 1

  2. Jak funguje TIME_FORMAT() v MariaDB

  3. Hostingový balíček na Chocolatey

  4. Jak databáze podporují podniky elektronického obchodu