Hlavní cíle nastavení multi-datacenter (nebo multi-DC) – bez ohledu na to, zda je databázovým ekosystémem SQL (PostgreSQL, MySQL) nebo NoSQL (MongoDB, Cassandra), abychom jmenovali alespoň některé – jsou nízká latence pro koncové uživatele, Vysoká dostupnost a zotavení po havárii. Jádrem takového prostředí je schopnost replikovat data způsoby, které zajišťují jejich trvanlivost (jako vedlejší poznámka, konfigurační parametry odolnosti Cassandry jsou podobné těm, které používá PostgreSQL). Různé požadavky na replikaci budou diskutovány níže, avšak extrémní případy budou ponechány zvědavcům pro další výzkum.
Replikace pomocí asynchronního odesílání protokolů je v PostgreSQL k dispozici již dlouhou dobu a synchronní replikace představená ve verzi 9.1 otevřela vývojářům nástrojů pro správu PostgreSQL zcela novou sadu možností.
Co je třeba zvážit
Jedním ze způsobů, jak porozumět složitosti implementace PostgreSQL multi-DC, je poučit se z řešení implementovaných pro jiné databázové systémy a zároveň mít na paměti, že PostgreSQL trvá na tom, aby byl kompatibilní s ACID.
Nastavení multi-DC obsahuje ve většině případů alespoň jedno datové centrum v cloudu. I když poskytovatelé cloudu přebírají břemeno správy replikace databáze jménem svých klientů, obvykle neodpovídají funkcím dostupným ve specializovaných nástrojích pro správu. Například s mnoha společnostmi, které využívají hybridní cloudová a/nebo multicloudová řešení, by navíc ke své stávající infrastruktuře na místě měl být nástroj pro multi-DC schopen zvládnout takto smíšené prostředí.
Dále, aby se minimalizovaly prostoje během převzetí služeb při selhání, systém správy PostgreSQL by měl být schopen požádat (prostřednictvím volání API) o aktualizaci DNS, takže databázové požadavky jsou směrovány do nového hlavního clusteru.
Sítě pokrývající velké geografické oblasti mají připojení s vysokou latencí a všechna řešení musí dělat kompromisy:zapomeňte na synchronní replikaci a použijte jednu primární s mnoha replikami pro čtení. Hloubkovou analýzu síťových efektů na replikaci najdete ve studiích AWS MongoDB a Somenines/Galera Cluster. V souvislosti s tím je šikovný nástroj pro testování latence mezi umístěními Wonder Network Ping Statistics.
I když povaha vysoké latence WAN nemůže být změněna, uživatelskou zkušenost lze dramaticky zlepšit zajištěním toho, že čtení budou obsluhována z repliky pro čtení v blízkosti umístění uživatele, avšak s určitými výhradami. Přesunutím replik od primárního se zápisy zpožďují, a proto musíme skoncovat se synchronní replikací. Řešení musí být také schopno vyřešit další problémy, jako je konzistence čtení po zápisu a zastaralé sekundární čtení kvůli ztrátě připojení.
Aby bylo možné minimalizovat RTO, je třeba data replikovat do odolného úložiště, které je také schopno zajistit vysokou propustnost čtení, a podle Citus Data je jednou z možností, která tyto požadavky splňuje, AWS S3.
Samotný pojem více datových center znamená, že systém správy databází musí být schopen prezentovat správci databází globální pohled na všechna datová centra a různé clustery PostgreSQL v nich, spravovat více verzí PostgreSQL a konfigurovat replikaci mezi nimi.
Při replikaci zápisů do regionálních datových center je třeba sledovat zpoždění šíření. Pokud zpoždění překročí prahovou hodnotu, měl by se spustit alarm, který indikuje, že replika obsahuje zastaralá data. Stejný princip platí pro asynchronní multi-master replikaci.
V synchronním nastavení může vysoká latence nebo narušení sítě vést ke zpoždění při vyřizování klientských požadavků při čekání na dokončení potvrzení, zatímco v asynchronních konfiguracích existuje riziko rozdělení mozku nebo snížení výkonu na delší dobu. Rozdělený mozek a zpoždění synchronních revizí jsou nevyhnutelné i v případě dobře zavedených replikačních řešení, jak je vysvětleno v článku Geo-Distributed Database Clusters with Galera.
Dalším aspektem je podpora dodavatele – v době psaní tohoto článku AWS nepodporuje repliky mezi regiony PostgreSQL.
Inteligentní řídicí systémy by měly monitorovat latenci sítě mezi datovými centry a doporučovat nebo upravovat změny, např. synchronní replikace je naprosto v pořádku mezi zónami dostupnosti AWS, kde jsou datová centra propojena pomocí optických sítí. Tímto způsobem může řešení dosáhnout nulové ztráty dat a může také implementovat replikaci master-master spolu s vyrovnáváním zátěže. Všimněte si, že AWS Aurora PostgreSQL aktuálně neposkytuje možnost replikace master-master.
Rozhodněte o úrovni replikace:cluster, databáze, tabulka. Kritéria rozhodování by měla zahrnovat náklady na šířku pásma.
Implementujte kaskádovou replikaci, abyste se vyhnuli narušení sítě, která mohou replikám bránit v přijímání aktualizací od hlavního serveru kvůli geografické vzdálenosti.
Řešení
S ohledem na všechny požadavky identifikujte produkty, které jsou pro danou práci nejvhodnější. Upozornění:každé řešení má svá vlastní upozornění, která je třeba řešit podle doporučení v dokumentaci k produktu. Viz například požadavek na monitorování BDR.
Oficiální dokumentace PostgreSQL obsahuje seznam nekomerčních aplikací s otevřeným zdrojovým kódem a rozšířený seznam včetně komerčních řešení s uzavřeným zdrojovým kódem lze nalézt na wiki stránce Replication, Clustering a Connection Pooling. Některé z těchto nástrojů byly podrobněji přezkoumány v článku Top PG Clustering HA Solutions for PostgreSQL.
Neexistuje žádné řešení na klíč, ale některé produkty mohou poskytnout většinu funkcí, zejména při spolupráci s dodavatelem.
Zde je neúplný seznam:
- Citus Data poskytují vlastní sestavení PostgreSQL, vylepšené o působivé podnikové funkce a hlubokou integraci s AWS.
- EnterpriseDB nabízí velkou sadu služeb, které lze kombinovat, aby splňovaly většinu požadavků. Většina informací je v dokumentaci k produktu.
- Postgres-BDR je výkonný replikační nástroj navržený speciálně pro geograficky distribuované clustery, nelze jej však integrovat s žádným poskytovatelem cloudu.
- ClusterControl přichází s působivou sadou funkcí – pro správu PostgreSQL. Má také omezenou cloudovou integraci.
- ElephantSQL funguje u mnoha poskytovatelů cloudu. Neexistuje však žádná možnost pro místní nastavení.
- Crunchy PostgreSQL pro Kubernetes je cloudový agnostický produkt postavený na upstream PostgreSQL.
Závěr
Jak jsme viděli, pokud jde o výběr řešení PostgreSQL pro více datových center, neexistuje univerzální řešení. Často jsou kompromisy nutností. Dobré pochopení požadavků a důsledků však může vést k informovanému rozhodování.
Ve srovnání se statickými daty (pouze pro čtení) musí řešení pro databáze brát v úvahu replikaci aktualizací (zápisů). Literatura popisující řešení replikace SQL i NoSQL trvá na použití jediného zdroje pravdy pro zápisy s mnoha replikami, aby se předešlo problémům, jako je rozdělení mozku a konzistence čtení po zápisu.
A konečně, interoperabilita je klíčovým požadavkem vzhledem k tomu, že nastavení více DC mohou zahrnovat datová centra umístěná na místě a různé poskytovatele cloudu.