Die Hauptziele eines Setups mit mehreren Rechenzentren (oder Multi-DC) – unabhängig davon, ob das Datenbank-Ökosystem SQL (PostgreSQL, MySQL) oder NoSQL (MongoDB, Cassandra) ist, um nur einige zu nennen – sind niedrige Latenz für Endbenutzer, Hochverfügbarkeit und Notfallwiederherstellung. Das Herzstück einer solchen Umgebung ist die Fähigkeit, Daten auf eine Weise zu replizieren, die ihre Dauerhaftigkeit gewährleistet (nebenbei bemerkt, die Dauerhaftigkeitskonfigurationsparameter von Cassandra ähneln denen, die von PostgreSQL verwendet werden). Die verschiedenen Replikationsanforderungen werden unten diskutiert, die Extremfälle werden jedoch den Neugierigen für weitere Forschung überlassen.
Die Replikation mit asynchronem Protokollversand ist in PostgreSQL seit langem verfügbar, und die in Version 9.1 eingeführte synchrone Replikation eröffnete Entwicklern von PostgreSQL-Verwaltungstools eine ganze Reihe neuer Optionen.
Was zu beachten ist
Eine Möglichkeit, die Komplexität einer PostgreSQL-Multi-DC-Implementierung zu verstehen, besteht darin, von den Lösungen zu lernen, die für andere Datenbanksysteme implementiert wurden, wobei zu berücksichtigen ist, dass PostgreSQL darauf besteht, ACID-konform zu sein.
Ein Multi-DC-Setup umfasst in den meisten Fällen mindestens ein Rechenzentrum in der Cloud. Während Cloud-Anbieter die Last der Verwaltung der Datenbankreplikation im Namen ihrer Kunden übernehmen, entsprechen sie normalerweise nicht den Funktionen, die in spezialisierten Verwaltungstools verfügbar sind. Da beispielsweise viele Unternehmen Hybrid-Cloud- und/oder Multi-Cloud-Lösungen einsetzen, sollte ein Multi-DC-Tool zusätzlich zu ihrer vorhandenen On-Premise-Infrastruktur in der Lage sein, eine solche gemischte Umgebung zu handhaben.
Um die Ausfallzeit während eines Failovers zu minimieren, sollte das PostgreSQL-Verwaltungssystem außerdem in der Lage sein, (über einen API-Aufruf) eine DNS-Aktualisierung anzufordern, sodass die Datenbankanforderungen an den neuen Master-Cluster weitergeleitet werden.
Netzwerke, die sich über große geografische Gebiete erstrecken, sind Verbindungen mit hoher Latenz, und alle Lösungen müssen Kompromisse eingehen:Vergessen Sie die synchrone Replikation und verwenden Sie eine primäre mit vielen Lesereplikaten. Eine eingehende Analyse der Netzwerkeffekte auf die Replikation finden Sie in den Studien zu AWS MongoDB und Multiplenines/Galera Cluster. In diesem Zusammenhang ist Wonder Network Ping Statistics ein raffiniertes Tool zum Testen der Latenz zwischen Standorten.
Während die hohe Latenz des WAN nicht geändert werden kann, kann die Benutzererfahrung erheblich verbessert werden, indem sichergestellt wird, dass Lesevorgänge von einer Read Replica in der Nähe des Benutzerstandorts bereitgestellt werden, jedoch mit einigen Einschränkungen. Durch das Verschieben von Replikaten vom primären Replikat werden Schreibvorgänge verzögert, und daher müssen wir die synchrone Replikation abschaffen. Die Lösung muss auch in der Lage sein, andere Probleme wie Read-after-Write-Konsistenz und veraltete sekundäre Lesevorgänge aufgrund von Verbindungsverlusten zu umgehen.
Um die RTO zu minimieren, müssen Daten auf einen dauerhaften Speicher repliziert werden, der auch einen hohen Lesedurchsatz bieten kann, und laut Citus Data ist AWS S3 eine Option, die diese Anforderungen erfüllt.
Allein die Vorstellung von mehreren Rechenzentren impliziert, dass das Datenbankverwaltungssystem in der Lage sein muss, dem DBA eine globale Ansicht aller Rechenzentren und der verschiedenen PostgreSQL-Cluster darin zu präsentieren, mehrere Versionen von PostgreSQL zu verwalten und die Replikation zwischen ihnen zu konfigurieren /P>
Beim Replizieren von Schreibvorgängen in regionale Rechenzentren muss die Ausbreitungsverzögerung überwacht werden. Wenn die Verzögerung einen Schwellenwert überschreitet, sollte ein Alarm ausgelöst werden, der anzeigt, dass die Kopie veraltete Daten enthält. Das gleiche Prinzip gilt für die asynchrone Multi-Master-Replikation.
In einem synchronen Setup können hohe Latenz oder Netzwerkunterbrechungen zu Verzögerungen bei der Bearbeitung von Client-Anforderungen führen, während auf den Abschluss des Commit gewartet wird, während in asynchronen Konfigurationen das Risiko eines Split-Brain oder einer verminderten Leistung über einen längeren Zeitraum besteht. Split-Brain und Verzögerungen bei synchronen Commits sind selbst mit etablierten Replikationslösungen unvermeidlich, wie im Artikel Geo-Distributed Database Clusters with Galera erläutert.
Ein weiterer Aspekt ist die Anbieterunterstützung – zum jetzigen Zeitpunkt unterstützt AWS keine regionsübergreifenden PostgreSQL-Replikate.
Intelligente Verwaltungssysteme sollten die Netzwerklatenz zwischen Rechenzentren überwachen und Änderungen empfehlen oder anpassen, z. Die synchrone Replikation ist zwischen AWS-Verfügbarkeitszonen, in denen Rechenzentren über Glasfasernetzwerke verbunden sind, vollkommen in Ordnung. Auf diese Weise kann eine Lösung keinen Datenverlust erreichen und auch eine Master-Master-Replikation zusammen mit einem Lastausgleich implementieren. Beachten Sie, dass AWS Aurora PostgreSQL derzeit keine Master-Master-Replikationsoption bietet.
Entscheiden Sie sich für die Replikationsebene:Cluster, Datenbank, Tabelle. Die Entscheidungskriterien sollten Bandbreitenkosten beinhalten.
Implementieren Sie die kaskadierte Replikation, um Netzwerkunterbrechungen zu umgehen, die aufgrund der geografischen Entfernung verhindern können, dass Replikate Updates vom Master erhalten.
Lösungen
Unter Berücksichtigung aller Anforderungen identifizieren Sie die Produkte, die für den Job am besten geeignet sind. Ein Hinweis zur Vorsicht:Jede Lösung hat ihre eigenen Vorbehalte, die behandelt werden müssen, indem die Empfehlungen in der Produktdokumentation befolgt werden. Siehe zum Beispiel die BDR-Überwachungsanforderung.
Die offizielle PostgreSQL-Dokumentation enthält eine Liste nichtkommerzieller Open-Source-Anwendungen, und eine erweiterte Liste mit kommerziellen Closed-Source-Lösungen finden Sie auf der Wiki-Seite Replication, Clustering, and Connection Pooling. Einige dieser Tools wurden im Artikel Top PG Clustering HA Solutions for PostgreSQL ausführlicher besprochen.
Es gibt keine schlüsselfertige Lösung, aber einige Produkte können die meisten Funktionen bereitstellen, insbesondere wenn Sie mit dem Anbieter zusammenarbeiten.
Hier ist eine nicht erschöpfende Liste:
- Citus Data stellt einen eigenen PostgreSQL-Build bereit, der um beeindruckende Unternehmensfunktionen und eine tiefe Integration mit AWS erweitert wurde.
- EnterpriseDB bietet eine große Suite von Diensten, die kombiniert werden können, um die meisten Anforderungen zu erfüllen. Die meisten Informationen finden Sie in der Produktdokumentation.
- Postgres-BDR ist ein leistungsstarkes Replikationstool, das speziell für geografisch verteilte Cluster entwickelt wurde, jedoch mit keinem Cloud-Anbieter integriert werden kann.
- ClusterControl verfügt über ein beeindruckendes Feature-Set zur Verwaltung von PostgreSQL. Es hat auch eine begrenzte Cloud-Integration.
- ElephantSQL funktioniert bei vielen Cloud-Anbietern. Es gibt jedoch keine Option für eine On-Premise-Einrichtung.
- Crunchy PostgreSQL für Kubernetes ist ein Cloud-agnostisches Produkt, das auf dem Upstream-PostgreSQL basiert.
Schlussfolgerung
Wie wir gesehen haben, gibt es bei der Auswahl einer PostgreSQL-Lösung für mehrere Rechenzentren keine Einheitslösung. Kompromisse sind oft ein Muss. Ein gutes Verständnis der Anforderungen und Auswirkungen kann jedoch zu einer fundierten Entscheidung beitragen.
Im Vergleich zu statischen (schreibgeschützten) Daten muss eine Lösung für Datenbanken die Replikation von Aktualisierungen (Schreibvorgänge) berücksichtigen. Die Literatur, die sowohl SQL- als auch NoSQL-Replikationslösungen beschreibt, besteht darauf, eine einzige Quelle der Wahrheit für Schreibvorgänge mit vielen Replikaten zu verwenden, um Probleme wie Split-Brain und Read-after-Write-Konsistenz zu vermeiden.
Schließlich ist die Interoperabilität eine wichtige Anforderung, wenn man bedenkt, dass Multi-DC-Setups Rechenzentren vor Ort und verschiedene Cloud-Anbieter umfassen können.
