Hovedmålene for et multi-datacenter (eller multi-DC) opsætning - uanset om databaseøkosystemet er SQL (PostgreSQL, MySQL) eller NoSQL (MongoDB, Cassandra) for blot at nævne nogle få - er Low Latency for slutbrugere, Høj tilgængelighed og gendannelse efter katastrofer. Kernen i et sådant miljø ligger evnen til at replikere data på måder, der sikrer deres holdbarhed (som en sidebemærkning, Cassandras holdbarhedskonfigurationsparametre ligner dem, der bruges af PostgreSQL). De forskellige replikationskrav vil blive diskuteret nedenfor, men de ekstreme tilfælde vil blive overladt til nysgerrige for yderligere forskning.
Replikering ved hjælp af asynkron logforsendelse har været tilgængelig i PostgreSQL i lang tid, og synkron replikering introduceret i version 9.1 åbnede et helt nyt sæt muligheder for udviklere af PostgreSQL-administrationsværktøjer.
Ting at overveje
En måde at forstå kompleksiteten af en PostgreSQL multi-DC-implementering er ved at lære af løsningerne implementeret til andre databasesystemer, mens man husker på, at PostgreSQL insisterer på at være ACID-kompatibel.
En multi-DC-opsætning inkluderer i de fleste tilfælde mindst ét datacenter i skyen. Mens cloud-udbydere påtager sig byrden med at administrere databasereplikeringen på vegne af deres kunder, matcher de normalt ikke de funktioner, der er tilgængelige i specialiserede administrationsværktøjer. For eksempel med mange virksomheder, der omfavner hybrid cloud- og/eller multi-cloud-løsninger, ud over deres eksisterende on-premise-infrastruktur, bør et multi-DC-værktøj være i stand til at håndtere et sådant blandet miljø.
For at minimere nedetid under en failover bør PostgreSQL-administrationssystemet være i stand til (via et API-kald) at anmode om en DNS-opdatering, så databaseanmodningerne dirigeres til den nye masterklynge.
Netværk, der spænder over store geografiske områder, er forbindelser med høj latenstid, og alle løsninger skal gå på kompromis:Glem alt om synkron replikering, og brug en primær med mange læste replikaer. Se AWS MongoDB og Severalnines/Galera Cluster undersøgelserne for en dybdegående analyse af netværkseffekter på replikering. På en relateret bemærkning er Wonder Network Ping Statistics et smart værktøj til at teste latenstiden mellem lokationer.
Selvom WAN's høje latenstid ikke kan ændres, kan brugeroplevelsen forbedres dramatisk ved at sikre, at læsninger serveres fra en læsereplika tæt på brugerens placering, dog med nogle forbehold. Ved at flytte replikaer væk fra det primære, forsinkes skrivninger, og vi må derfor gøre op med synkron replikering. Løsningen skal også være i stand til at omgå andre problemer såsom læs-efter-skriv-konsistens og forældede sekundære læsninger på grund af forbindelsestab.
For at minimere RTO'en skal data replikeres til et holdbart lager, der også er i stand til at give høj læsegennemstrømning, og ifølge Citus Data er en mulighed, der opfylder disse krav, AWS S3.
Selve begrebet multiple datacenter indebærer, at databasestyringssystemet skal være i stand til at præsentere DBA med et globalt overblik over alle datacentre og de forskellige PostgreSQL-klynger i dem, administrere flere versioner af PostgreSQL og konfigurere replikeringen mellem dem.
Ved replikering af skrivninger til regionale datacentre skal udbredelsesforsinkelsen overvåges. Hvis forsinkelsen overstiger en tærskel, skal der udløses en alarm, der indikerer, at replikaen indeholder forældede data. Det samme princip gælder for asynkron multi-master replikering.
I en synkron opsætning kan høj latens eller netværksafbrydelser føre til forsinkelser i betjening af klientanmodninger, mens man venter på, at commit er fuldført, mens der i asynkrone konfigurationer er risiko for split-brain eller forringet ydeevne i en længere periode. Split-brain og forsinkelser på synkrone commits er uundgåelige selv med veletablerede replikeringsløsninger som forklaret i artiklen Geo-Distributed Database Clusters with Galera.
En anden overvejelse er leverandørsupport - i skrivende stund understøtter AWS ikke PostgreSQL-replikaer på tværs af regioner.
Intelligente styringssystemer bør overvåge netværksforsinkelsen mellem datacentre og anbefale eller justere ændringer f.eks. synkron replikering er helt i orden mellem AWS Availability Zones, hvor datacentre er forbundet ved hjælp af fibernetværk. På den måde kan en løsning opnå nul datatab, og den kan også implementere master-master replikering sammen med belastningsbalancering. Bemærk, at AWS Aurora PostgreSQL i øjeblikket ikke tilbyder en master-master-replikeringsmulighed.
Beslut dig for replikeringsniveauet:klynge, database, tabel. Beslutningskriterierne bør omfatte båndbreddeomkostninger.
Implementer kaskadedelt replikering for at omgå netværksafbrydelser, der kan forhindre replikaer i at modtage opdateringer fra master på grund af geografisk afstand.
Løsninger
Under hensyntagen til alle kravene identificeres de produkter, der er bedst egnede til jobbet. Dog en advarsel:hver løsning kommer med sine egne forbehold, som skal håndteres ved at følge anbefalingerne i produktdokumentationen. Se for eksempel BDR-overvågningskravet.
Den officielle PostgreSQL-dokumentation indeholder en liste over ikke-kommercielle open source-applikationer, og en udvidet liste med kommercielle lukkede kilder-løsninger kan findes på wikisiden for replikering, klyngedannelse og forbindelsespooling. Et par af disse værktøjer er blevet gennemgået mere detaljeret i artiklen Top PG Clustering HA Solutions for PostgreSQL.
Der er ingen nøglefærdig løsning, men nogle produkter kan give de fleste funktioner, især når du arbejder med leverandøren.
Her er en ikke-udtømmende liste:
- Citus Data leverer deres egen PostgreSQL-build, forbedret med imponerende virksomhedsfunktioner og dyb integration med AWS.
- EnterpriseDB tilbyder en stor pakke af tjenester, der kan kombineres for at opfylde de fleste af kravene. De fleste oplysninger findes i produktdokumentation.
- Postgres-BDR er et kraftfuldt replikeringsværktøj designet specifikt til geografisk distribuerede klynger, men det kan ikke integreres med nogen cloud-udbyder.
- ClusterControl kommer med et imponerende funktionssæt - til styring af PostgreSQL. Den har også begrænset cloud-integration.
- ElephantSQL fungerer på tværs af mange cloud-udbydere. Der er dog ingen mulighed for en lokal opsætning.
- Crunchy PostgreSQL til Kubernetes er et cloud-agnostisk produkt bygget på opstrøms PostgreSQL.
Konklusion
Som vi har set, når det kommer til at vælge en PostgreSQL multi-datacenter-løsning, er der ikke en løsning, der passer til alle. Ofte er det et must at gå på kompromis. En god forståelse af kravene og implikationerne kan dog være med til at træffe en informeret beslutning.
Sammenlignet med statiske (skrivebeskyttede) data skal en løsning til databaser overveje replikering af opdateringer (skriver). Litteraturen, der beskriver både SQL- og NoSQL-replikeringsløsninger, insisterer på at bruge en enkelt kilde til sandhed til skrivninger med mange replikaer for at undgå problemer såsom split-brain og læs-efter-skriv-konsistens.
Endelig er interoperabilitet et nøglekrav i betragtning af, at multi-DC-opsætninger kan spænde over datacentre, der er placeret på stedet, og forskellige cloud-udbydere.