Huvudmålen för en multi-datacenter (eller multi-DC) installation – oavsett om databasen ekosystem är SQL (PostgreSQL, MySQL) eller NoSQL (MongoDB, Cassandra) för att bara nämna några – är Low Latency för slutanvändare, Hög tillgänglighet och katastrofåterställning. Kärnan i en sådan miljö ligger förmågan att replikera data, på ett sätt som säkerställer dess hållbarhet (som en sidoanteckning Cassandras hållbarhetskonfigurationsparametrar liknar de som används av PostgreSQL). De olika replikeringskraven kommer att diskuteras nedan, men de extrema fallen kommer att lämnas till nyfikna för vidare forskning.
Replikering med asynkron loggsändning har varit tillgänglig i PostgreSQL under lång tid, och synkron replikering som introducerades i version 9.1 öppnade en helt ny uppsättning alternativ för utvecklare av PostgreSQL-hanteringsverktyg.
Saker att tänka på
Ett sätt att förstå komplexiteten i en PostgreSQL multi-DC-implementering är genom att lära av lösningarna som implementeras för andra databassystem, samtidigt som man kommer ihåg att PostgreSQL insisterar på att vara ACID-kompatibel.
En multi-DC-installation inkluderar i de flesta fall minst ett datacenter i molnet. Även om molnleverantörer tar på sig bördan av att hantera databasreplikeringen på uppdrag av sina kunder, matchar de vanligtvis inte funktionerna som finns tillgängliga i specialiserade hanteringsverktyg. Till exempel med många företag som anammar hybridmoln och/eller multimolnlösningar, utöver sin befintliga lokalbaserade infrastruktur, borde ett multi-DC-verktyg kunna hantera en sådan blandad miljö.
Vidare, för att minimera driftstopp under en failover, bör PostgreSQL-hanteringssystemet kunna begära (via ett API-anrop) en DNS-uppdatering, så att databasförfrågningarna dirigeras till det nya huvudklustret.
Nätverk som spänner över stora geografiska områden är anslutningar med hög latens och alla lösningar måste kompromissa:glöm synkron replikering och använd en primär med många läsrepliker. Se AWS MongoDB och Severalnines/Galera Cluster-studierna för en djupgående analys av nätverkseffekter på replikering. På en relaterad anteckning är Wonder Network Ping Statistics ett smart verktyg för att testa latensen mellan platser.
Även om WAN-karaktären med hög latens inte kan ändras, kan användarupplevelsen förbättras dramatiskt genom att se till att läsningar levereras från en läsreplika nära användarens plats, dock med vissa förbehåll. Genom att flytta repliker bort från det primära försenas skrivningar och därför måste vi göra oss av med synkron replikering. Lösningen måste också kunna hantera andra problem som läs-efter-skriv-konsistens och inaktuella sekundära läsningar på grund av anslutningsbortfall.
För att minimera RTO måste data replikeras till en hållbar lagring som också kan ge hög läskapacitet, och enligt Citus Data är ett alternativ som uppfyller dessa krav AWS S3.
Själva begreppet multipeldatacenter innebär att databashanteringssystemet måste kunna presentera DBA med en global bild av alla datacenter och de olika PostgreSQL-klustren inom dem, hantera flera versioner av PostgreSQL och konfigurera replikeringen mellan dem.
Vid replikering av skrivningar till regionala datacenter måste spridningsfördröjningen övervakas. Om fördröjningen överstiger ett tröskelvärde ska ett larm utlösas som indikerar att kopian innehåller inaktuella data. Samma princip gäller för asynkron multimasterreplikering.
I en synkron installation kan hög latens eller nätverksstörningar leda till förseningar i att betjäna klientförfrågningar i väntan på att commit ska slutföras, medan det i asynkrona konfigurationer finns risker för split-brain eller försämrad prestanda under en längre tidsperiod. Split-brain och fördröjningar på synkrona commits är oundvikliga även med väletablerade replikeringslösningar som förklaras i artikeln Geo-Distributed Database Clusters with Galera.
Ett annat övervägande är leverantörsstöd – när detta skrivs stöder AWS inte PostgreSQL-repliker över regioner.
Intelligenta ledningssystem bör övervaka nätverkslatensen mellan datacenter och rekommendera eller justera ändringar t.ex. synkron replikering är perfekt mellan AWS Availability Zones där datacenter är anslutna med fibernätverk. På så sätt kan en lösning uppnå noll dataförlust och den kan också implementera master-master replikering tillsammans med lastbalansering. Observera att AWS Aurora PostgreSQL för närvarande inte tillhandahåller ett master-master-replikeringsalternativ.
Bestäm replikeringsnivån:kluster, databas, tabell. Beslutskriterierna bör inkludera bandbreddskostnader.
Implementera kaskadreplikering för att undvika nätverksavbrott som kan förhindra att repliker tar emot uppdateringar från master på grund av geografiskt avstånd.
Lösningar
Med hänsyn till alla krav identifiera de produkter som är bäst lämpade för jobbet. En notering av försiktighet dock:varje lösning kommer med sina egna varningar som måste hanteras genom att följa rekommendationerna i produktdokumentationen. Se till exempel BDR-övervakningskravet.
Den officiella PostgreSQL-dokumentationen innehåller en lista över icke-kommersiella applikationer med öppen källkod, och en utökad lista med kommersiella lösningar med sluten källkod finns på wikisidan för replikering, klustering och anslutningspool. Några av dessa verktyg har granskats mer i detalj i artikeln Top PG Clustering HA Solutions for PostgreSQL.
Det finns ingen nyckelfärdig lösning, men vissa produkter kan tillhandahålla de flesta funktioner, särskilt när du arbetar med leverantören.
Här är en icke uttömmande lista:
- Citus Data tillhandahåller sin egen PostgreSQL-byggnad, förbättrad med imponerande företagsfunktioner och djup integration med AWS.
- EnterpriseDB erbjuder en stor uppsättning tjänster som kan kombineras för att uppfylla de flesta kraven. Mest information finns i produktdokumentationen.
- Postgres-BDR är ett kraftfullt replikeringsverktyg designat specifikt för geografiskt distribuerade kluster, men det integreras inte med någon molnleverantör.
- ClusterControl kommer med en imponerande funktionsuppsättning för att hantera PostgreSQL. Den har också begränsad molnintegration.
- ElephantSQL fungerar på många molnleverantörer. Det finns dock inget alternativ för en lokal installation.
- Crunchy PostgreSQL för Kubernetes är en molnagnostisk produkt byggd på uppströms PostgreSQL.
Slutsats
Som vi har sett, när det gäller att välja en PostgreSQL-multidatacenterlösning, finns det inte en lösning som passar alla. Ofta är det ett måste att kompromissa. En god förståelse för kraven och konsekvenserna kan dock räcka långt för att fatta ett välgrundat beslut.
Jämfört med statiska (skrivskyddade) data måste en lösning för databaser överväga replikering av uppdateringar (skriver). Litteraturen som beskriver både SQL- och NoSQL-replikeringslösningar insisterar på att använda en enda källa till sanning för skrivningar med många repliker för att undvika problem som split-brain och läs-efter-skriv-konsistens.
Slutligen är interoperabilitet ett nyckelkrav med tanke på att multi-DC-konfigurationer kan sträcka sig över datacenter lokaliserade och olika molnleverantörer.