Je docela běžné vidět databáze distribuované v různých geografických lokalitách. Jedním ze scénářů pro provedení tohoto typu nastavení je zotavení po havárii, kdy je vaše záložní datové centrum umístěno na jiném místě než vaše hlavní datové centrum. Může být také požadováno, aby byly databáze umístěny blíže uživatelům.
Hlavním problémem k dosažení tohoto nastavení je navržení databáze způsobem, který snižuje možnost problémů souvisejících s rozdělením sítě. Jedním z řešení může být použití Galera Cluster namísto běžné asynchronní (nebo semisynchronní) replikace. V tomto blogu budeme diskutovat o výhodách a nevýhodách tohoto přístupu. Toto je první díl ze série dvou blogů. Ve druhé části navrhneme geograficky distribuovaný Galera Cluster a uvidíme, jak nám ClusterControl může pomoci nasadit takové prostředí.
Proč klastr Galera místo asynchronní replikace pro geograficky distribuované klastry?
Podívejme se na hlavní rozdíly mezi Galerou a běžnou replikací. Pravidelná replikace vám poskytuje pouze jeden uzel pro zápis, což znamená, že každý zápis ze vzdáleného datového centra by musel být odeslán přes Wide Area Network (WAN), aby se dostal k master. Znamená to také, že všechny proxy umístěné ve vzdáleném datovém centru budou muset být schopny monitorovat celou topologii napříč všemi zapojenými datovými centry, protože musí být schopny zjistit, který uzel je aktuálně hlavním.
To vede k množství problémů. Za prvé, musí být vytvořeno více připojení přes WAN, což zvyšuje latenci a zpomaluje veškeré kontroly, zda proxy může být spuštěna. Navíc to přidává zbytečnou režii na servery proxy a databáze. Většinu času vás zajímá pouze směrování provozu do uzlů místní databáze. Jedinou výjimkou je master a jen kvůli tomu jsou proxy nuceny hlídat celou infrastrukturu a ne jen část umístěnou v lokálním datacentru. Samozřejmě se to můžete pokusit překonat tak, že použijete proxy pro směrování pouze SELECTů, zatímco použijete nějakou jinou metodu (vyhrazený název hostitele pro master spravovaného DNS) k nasměrování aplikace na master, ale to přidává zbytečné úrovně složitosti a pohyblivých částí, které může vážně ovlivnit vaši schopnost zvládnout vícenásobná selhání uzlů a sítě bez ztráty konzistence dat.
Galera Cluster může podporovat více autorů. Latence je také faktorem, protože všechny uzly v clusteru Galera se musí koordinovat a komunikovat, aby certifikovaly sady zápisů, může to být dokonce důvod, proč se můžete rozhodnout Galeru nepoužívat, když je latence příliš vysoká. Je to také problém v replikačních klastrech – v replikačních klastrech latence ovlivňuje pouze zápisy ze vzdálených datových center, zatímco připojení z datového centra, kde se nachází master, by těžila z nízké latence potvrzení.
V replikaci MySQL musíte také vzít v úvahu nejhorší možný scénář a zajistit, aby aplikace byla v pořádku se zpožděnými zápisy. Master se může vždy změnit a nemůžete si být jisti, že po celou dobu budete psát do místního uzlu.
Dalším rozdílem mezi replikací a Galera Cluster je zpracování zpoždění replikace. Geo-distribuované clustery mohou být vážně ovlivněny zpožděním:latence, omezená propustnost připojení WAN, to vše ovlivní schopnost replikovaného clusteru držet krok s replikací. Mějte prosím na paměti, že replikace generuje jeden pro veškerý provoz.
Všechny podřízené jednotky musí přijímat celý replikační provoz – množství dat, které máte počet odesílání vzdáleným podřízeným zařízením přes WAN se zvyšuje s každým vzdáleným podřízeným zařízením, které přidáte. To může snadno vést k saturaci spojení WAN, zvláště pokud provádíte mnoho úprav a spojení WAN nemá dobrou propustnost. Jak můžete vidět na obrázku výše, se třemi datovými centry a třemi uzly v každém z nich musí master posílat 6x více replikačního provozu přes WAN připojení.
U clusteru Galera jsou věci trochu jiné. Pro začátek, Galera používá řízení toku k udržení synchronizace uzlů. Pokud jeden z uzlů začne zaostávat, má schopnost požádat zbytek clusteru, aby zpomalil a nechal jej dohnat. Jistě, snižuje se tím výkon celého clusteru, ale stále je to lepší, než když nemůžete skutečně použít podřízené jednotky pro SELECTy, protože mají čas od času tendenci se zpožďovat – v takových případech mohou být výsledky, které dostanete, zastaralé a nesprávné.
Další funkce Galera Cluster, která může výrazně zlepšit jeho výkon při použití WAN, jsou segmenty. Ve výchozím nastavení Galera používá vše pro veškerou komunikaci a každou sadu zápisů posílá uzel všem ostatním uzlům v clusteru. Toto chování lze změnit pomocí segmentů. Segmenty umožňují uživatelům rozdělit cluster Galera na několik částí. Každý segment může obsahovat více uzlů a zvolí jeden z nich jako přenosový uzel. Takový uzel přijímá sady zápisů z jiných segmentů a přerozděluje je mezi uzly Galera, které jsou v daném segmentu místní. V důsledku toho, jak můžete vidět na výše uvedeném diagramu, je možné snížit replikační provoz jdoucí přes WAN třikrát – přes WAN se odesílají pouze dvě „repliky“ replikačního toku:jedna na datové centrum ve srovnání s jednou na slave v MySQL Replication.
Ovládání dělení v síti clusteru Galera
Kde Galera Cluster září, je zpracování síťového rozdělení. Galera Cluster neustále monitoruje stav uzlů v clusteru. Každý uzel se pokouší spojit se svými partnery a vyměnit si stav clusteru. Pokud není podmnožina uzlů dosažitelná, Galera se pokusí přenést komunikaci, takže pokud existuje způsob, jak se k těmto uzlům dostat, budou dosaženy.
Příklad je vidět na výše uvedeném diagramu:DC 1 ztratil připojení s DC2, ale DC2 a DC3 se mohou připojit. V tomto případě bude jeden z uzlů v DC3 použit k přenosu dat z DC1 do DC2, což zajistí, že komunikace uvnitř clusteru bude zachována.
Cluster Galera je schopen provádět akce na základě stavu clusteru. Implementuje kvorum - většina uzlů musí být k dispozici, aby mohl cluster fungovat. Pokud se uzel odpojí od clusteru a nemůže dosáhnout žádného jiného uzlu, přestane fungovat.
Jak je vidět na obrázku výše, došlo k částečné ztrátě síťové komunikace v DC1 a postižený uzel je odstraněn z clusteru, což zajišťuje, že aplikace nebude přistupovat k zastaralým datům.
To platí i ve větším měřítku. DC1 přerušila veškerou komunikaci. V důsledku toho bylo z clusteru odstraněno celé datové centrum a žádný z jeho uzlů nebude provoz obsluhovat. Zbytek clusteru si udržel většinu (6 z 9 uzlů je k dispozici) a sám se překonfiguroval, aby zachoval spojení mezi DC 2 a DC3. Ve výše uvedeném diagramu jsme předpokládali, že zápis zasáhne uzel v DC2, ale mějte prosím na paměti, že Galera může běžet s více zapisovači.
MySQL Replication nemá žádný druh povědomí o clusteru, takže je problematické řešit problémy se sítí. Nemůže se sám vypnout při ztrátě spojení s jinými uzly. Neexistuje žádný snadný způsob, jak zabránit tomu, aby se starý master objevil po rozdělení sítě.
Jediné možnosti jsou omezeny na vrstvu proxy nebo ještě vyšší. Musíte navrhnout systém, který se bude snažit porozumět stavu clusteru a podniknout potřebné kroky. Jedním z možných způsobů je použít nástroje podporující clustery, jako je Orchestrator, a poté spouštět skripty, které by kontrolovaly stav clusteru Orchestrator RAFT a na základě tohoto stavu prováděly požadované akce na databázové vrstvě. To není zdaleka ideální, protože jakákoli akce provedená na vrstvě vyšší než databáze přidává další latenci:umožňuje to, aby se problém projevil a konzistence dat je ohrožena dříve, než lze provést správnou akci. Na druhé straně Galera provádí akce na úrovni databáze a zajišťuje tak nejrychlejší možnou reakci.