De belangrijkste doelen van een multi-datacenter (of multi-DC) setup - ongeacht of het database-ecosysteem SQL (PostgreSQL, MySQL) of NoSQL (MongoDB, Cassandra) is om er maar een paar te noemen - zijn lage latentie voor eindgebruikers, Hoge beschikbaarheid en noodherstel. De kern van een dergelijke omgeving is de mogelijkheid om gegevens te repliceren, op een manier die de duurzaamheid ervan garandeert (terzijde:Cassandra's duurzaamheidsconfiguratieparameters zijn vergelijkbaar met die van PostgreSQL). De verschillende replicatievereisten zullen hieronder worden besproken, maar de extreme gevallen zullen aan de nieuwsgierigen worden overgelaten voor verder onderzoek.
Replicatie met behulp van asynchrone verzending van logbestanden is al heel lang beschikbaar in PostgreSQL en synchrone replicatie, geïntroduceerd in versie 9.1, opende een geheel nieuwe reeks opties voor ontwikkelaars van PostgreSQL-beheertools.
Dingen om te overwegen
Een manier om de complexiteit van een PostgreSQL multi-DC-implementatie te begrijpen, is door te leren van de oplossingen die voor andere databasesystemen zijn geïmplementeerd, terwijl u er rekening mee houdt dat PostgreSQL erop staat ACID-compatibel te zijn.
Een multi-DC opstelling omvat in de meeste gevallen minimaal één datacenter in de cloud. Hoewel cloudproviders de last van het beheer van de databasereplicatie namens hun klanten op zich nemen, komen ze meestal niet overeen met de functies die beschikbaar zijn in gespecialiseerde beheertools. Met veel ondernemingen die bijvoorbeeld hybride cloud- en/of multicloud-oplossingen omarmen, naast hun bestaande on-premise infrastructuur, zou een multi-DC-tool in staat moeten zijn om met zo'n gemengde omgeving om te gaan.
Om de downtime tijdens een failover tot een minimum te beperken, moet het PostgreSQL-beheersysteem in staat zijn om (via een API-aanroep) een DNS-update aan te vragen, zodat de databaseverzoeken naar het nieuwe hoofdcluster worden gerouteerd.
Netwerken die grote geografische gebieden beslaan, zijn verbindingen met een hoge latentie en alle oplossingen moeten compromissen sluiten:vergeet synchrone replicatie en gebruik één primaire met veel leesreplica's. Zie de AWS MongoDB en Verscheidenenines/Galera Cluster-onderzoeken voor een diepgaande analyse van netwerkeffecten op replicatie. Een handige tool voor het testen van de latentie tussen locaties is Wonder Network Ping Statistics.
Hoewel de hoge latentie van WAN niet kan worden veranderd, kan de gebruikerservaring drastisch worden verbeterd door ervoor te zorgen dat de leesbewerkingen worden uitgevoerd vanaf een leesreplica dicht bij de gebruikerslocatie, maar met enkele kanttekeningen. Door replica's weg te halen van de primaire, worden schrijfbewerkingen vertraagd en dus moeten we synchrone replicatie afschaffen. De oplossing moet ook andere problemen kunnen omzeilen, zoals lees-na-schrijfconsistentie en verouderde secundaire leesbewerkingen als gevolg van verbindingsverlies.
Om de RTO te minimaliseren, moeten gegevens worden gerepliceerd naar een duurzame opslag die ook een hoge leesdoorvoer kan bieden, en volgens Citus Data is AWS S3 een optie die aan deze vereisten voldoet.
Het idee van meerdere datacenters houdt in dat het databasebeheersysteem in staat moet zijn om de DBA een globaal overzicht te geven van alle datacenters en de verschillende PostgreSQL-clusters daarbinnen, meerdere versies van PostgreSQL te beheren en de replicatie daartussen te configureren.
Bij het repliceren van schrijfbewerkingen naar regionale datacenters moet de propagatievertraging worden bewaakt. Als de vertraging een drempel overschrijdt, moet een alarm worden geactiveerd om aan te geven dat de replica verouderde gegevens bevat. Hetzelfde principe is van toepassing op asynchrone multi-master replicatie.
In een synchrone setup kunnen hoge latentie of netwerkstoringen leiden tot vertragingen bij het afhandelen van clientverzoeken terwijl wordt gewacht tot de commit is voltooid, terwijl in asynchrone configuraties er risico's zijn van split-brain of verslechterde prestaties gedurende een langere periode. Split-brain en vertragingen bij synchrone commits zijn onvermijdelijk, zelfs met gevestigde replicatieoplossingen, zoals uitgelegd in het artikel Geo-Distributed Database Clusters met Galera.
Een andere overweging is de ondersteuning van leveranciers. Op het moment van schrijven ondersteunt AWS geen PostgreSQL-replica's voor meerdere regio's.
Intelligente beheersystemen moeten de netwerklatentie tussen datacenters bewaken en wijzigingen aanbevelen of aanpassen, b.v. synchrone replicatie is prima tussen AWS-beschikbaarheidszones waar datacenters zijn aangesloten via glasvezelnetwerken. Op die manier kan een oplossing nul gegevensverlies bereiken en kan het ook master-master-replicatie implementeren, samen met taakverdeling. Merk op dat AWS Aurora PostgreSQL momenteel geen master-master replicatie-optie biedt.
Bepaal het niveau van replicatie:cluster, database, tabel. De beslissingscriteria moeten bandbreedtekosten omvatten.
Implementeer trapsgewijze replicatie om netwerkstoringen te omzeilen die kunnen voorkomen dat replica's updates van de master ontvangen vanwege geografische afstand.
Oplossingen
Rekening houdend met alle vereisten, identificeer de producten die het meest geschikt zijn voor de taak. Een waarschuwing echter:elke oplossing heeft zijn eigen kanttekeningen die moeten worden opgelost door de aanbevelingen in de productdocumentatie te volgen. Zie bijvoorbeeld de BDR-bewakingsvereiste.
De officiële documentatie van PostgreSQL bevat een lijst met niet-commerciële open source-applicaties, en een uitgebreide lijst met commerciële closed source-oplossingen is te vinden op de wikipagina Replication, Clustering, and Connection Pooling. Een paar van die tools zijn in meer detail besproken in het artikel Top PG Clustering HA Solutions for PostgreSQL.
Er is geen kant-en-klare oplossing, maar sommige producten kunnen de meeste functies bieden, vooral in samenwerking met de leverancier.
Hier is een niet-limitatieve lijst:
- Citus Data biedt hun eigen PostgreSQL-build, verbeterd met indrukwekkende enterprise-functies en diepe integratie met AWS.
- EnterpriseDB biedt een groot aantal services die kunnen worden gecombineerd om aan de meeste vereisten te voldoen. De meeste informatie staat op Productdocumentatie.
- Postgres-BDR is een krachtige replicatietool die speciaal is ontworpen voor geografisch verspreide clusters, maar kan met geen enkele cloudprovider worden geïntegreerd.
- ClusterControl wordt geleverd met een indrukwekkende functieset voor het beheren van PostgreSQL. Het heeft ook beperkte cloudintegratie.
- ElephantSQL werkt voor veel cloudproviders. Er is echter geen optie voor een installatie op locatie.
- Crunchy PostgreSQL voor Kubernetes is een cloudonafhankelijk product dat is gebouwd op de upstream PostgreSQL.
Conclusie
Zoals we hebben gezien, is er geen pasklare oplossing als het gaat om het kiezen van een PostgreSQL-multidatacenteroplossing. Compromissen sluiten is vaak een must. Een goed begrip van de vereisten en implicaties kan echter een grote bijdrage leveren aan het nemen van een weloverwogen beslissing.
In vergelijking met statische (alleen-lezen) gegevens, moet een oplossing voor databases rekening houden met de replicatie van updates (schrijfbewerkingen). De literatuur die zowel SQL- als NoSQL-replicatieoplossingen beschrijft, dringt aan op het gebruik van één enkele bron van waarheid voor schrijfbewerkingen met veel replica's om problemen zoals split-brain en consistentie tussen lezen en schrijven te voorkomen.
Ten slotte is interoperabiliteit een belangrijke vereiste, aangezien multi-DC-configuraties zich kunnen uitstrekken over datacenters op locatie en verschillende cloudproviders.