Auf dieser Seite wird Hochverfügbarkeit beschrieben und die Tools, die wir empfehlen.
Datenausfallsicherheit
Die Datenresilienz lässt sich anhand von Verfügbarkeit, Zeit bis zur Wiederherstellung des Dienstes und Datenverlust messen. Die Verfügbarkeit wird in der Regel anhand der Betriebszeit gemessen und als Prozentsatz der Zeit ausgedrückt, in der die Datenbank verfügbar ist. Wenn Sie beispielsweise eine Verfügbarkeit von 99,99% erreichen möchten, darf Ihre Datenbank nicht länger als 52,6 Minuten pro Jahr oder 4,38 Minuten pro Monat ausfallen. Die Zeit, die zur Wiederherstellung eines Dienstes nach einem Ausfall benötigt wird, wird als Recovery Time Objective (RTO) bezeichnet. Die Menge an akzeptablem Datenverlust aufgrund eines Ausfalls wird als Recovery Point Objective (RPO) bezeichnet und als die Zeitspanne ausgedrückt, in der Transaktionen verloren gehen. Ein RPO von 10 Minuten bedeutet beispielsweise, dass Sie im Falle eines Fehlers bis zu 10 Minuten an Daten verlieren könnten.
Es ist üblich, ein Verfügbarkeitsziel oder Service Level Objective (SLO) zusammen mit Zielen für RTO und RPO festzulegen. Für eine bestimmte Arbeitslast können Sie das SLO beispielsweise auf 99,99 % festlegen und außerdem einen RPO von 0, keinen Datenverlust bei einem Fehler und einen RTO von 30 Sekunden festlegen. Für eine andere Arbeitslast legen Sie das SLO möglicherweise auf 99,9%, den RPO auf 5 Minuten und den RTO auf 10 Minuten fest.
Mit Datenbanksicherungen können Sie eine grundlegende Datenbankresilienz implementieren. AlloyDB Omni unterstützt Sicherungen mit pgBackRest und archiviert auch die WAL-Dateien (Write Ahead Log) der Datenbank, um Datenverlust zu minimieren. Wenn Ihre primäre Datenbank ausfällt, kann sie mit diesem Ansatz aus einer Sicherung mit einem RPO von wenigen Minuten und einem RTO von wenigen Minuten bis Stunden wiederhergestellt werden, je nach Größe der Datenbank.
Bei strengeren RPO- und RTO-Anforderungen können Sie AlloyDB Omni in einer Hochverfügbarkeitskonfiguration mit Patroni einrichten. In dieser Architektur gibt es eine primäre Datenbank und zwei Standby- oder Replikatdatenbanken. Sie können AlloyDB Omni so konfigurieren, dass die standardmäßige PostgreSQL-Streamingreplikation verwendet wird. So wird jede Transaktion, die auf dem primären Knoten committet wird, synchron auf beide Standby-Datenbanken repliziert. Dies führt zu einem RPO von null und einem RTO von weniger als 60 Sekunden für die meisten Fehlerszenarien.
Je nach Clusterkonfiguration kann sich die synchrone Replikation auf die Reaktionszeit für Transaktionen auswirken. Sie können auch ein geringes Risiko für Datenverlust eingehen. Sie können beispielsweise einen RPO-Wert ungleich null in Kauf nehmen, um eine geringere Transaktionslatenz zu erzielen, indem Sie Hochverfügbarkeit mit asynchroner anstelle von synchroner Replikation implementieren. Aufgrund der potenziellen Auswirkungen der synchronen Replikation auf die Transaktionslatenz werden Architekturen mit hoher Verfügbarkeit fast immer in einem einzelnen Rechenzentrum oder zwischen Rechenzentren implementiert, die nah beieinander liegen (wenige Kilometer entfernt / <10 Millisekunden Latenz). In dieser Dokumentation wird jedoch standardmäßig die synchrone Replikation verwendet.
Für die Notfallwiederherstellung, die Schutz vor dem Verlust eines Rechenzentrums oder einer Region mit mehreren Rechenzentren in unmittelbarer Nähe bietet, kann AlloyDB Omni mit asynchroner Streamingreplikation von der primären Region in eine sekundäre Region konfiguriert werden, die in der Regel Hunderte oder Tausende von Kilometern oder 10 bis 100 Millisekunden entfernt ist. In dieser Konfiguration wird die primäre Region mit synchroner Streamingreplikation zwischen der primären Datenbank und der Standby-Datenbank innerhalb der Region konfiguriert. Die asynchrone Streamingreplikation wird von der primären Region in eine oder mehrere sekundäre Regionen konfiguriert. AlloyDB Omni kann in der sekundären Region mit mehreren Datenbankinstanzen konfiguriert werden, um sicherzustellen, dass sie unmittelbar nach einem Failover aus der primären Region geschützt ist.
Funktionsweise der Hochverfügbarkeit
Die spezifischen Techniken und Tools, die zur Implementierung von Hochverfügbarkeit für Datenbanken verwendet werden, können je nach Datenbankverwaltungssystem variieren. Im Folgenden finden Sie einige der Techniken und Tools, die normalerweise bei der Implementierung von Hochverfügbarkeit für Datenbanken verwendet werden. Diese können je nach Datenbankverwaltungssystem variieren:
Redundanz: Wenn Sie Ihre Datenbank auf mehreren Servern oder in mehreren geografischen Regionen replizieren, haben Sie Failover-Optionen, falls eine primäre Instanz ausfällt.
Automatisches Failover: Mechanismus zum Erkennen von Fehlern und nahtlosen Wechsel zu einem fehlerfreien Replikat, um Ausfallzeiten zu minimieren. Abfragen werden so weitergeleitet, dass Anwendungsanfragen den neuen primären Knoten erreichen.
Datenkontinuität: Es werden Sicherheitsmaßnahmen implementiert, um die Datenintegrität bei Ausfällen zu schützen. Dazu gehören Replikationstechniken und Datenkonsistenzprüfungen.
Clustering: Beim Clustering werden mehrere Datenbankserver gruppiert, damit sie als einzelnes System zusammenarbeiten. So sind alle Knoten im Cluster aktiv und verarbeiten Anfragen, was für Load-Balancing und Redundanz sorgt.
Fallback: Methoden, um zur ursprünglichen Architektur zurückzukehren. Dabei werden der primäre Knoten und der Replikatknoten mit ihrer ursprünglichen Kapazität vor dem Failover verwendet.
Load-Balancing: Durch die Verteilung von Datenbankanfragen auf mehrere Instanzen wird die Leistung verbessert und mehr Traffic kann verarbeitet werden.
Monitoring und Benachrichtigungen: Monitoring-Tools erkennen Probleme wie Serverausfälle, hohe Latenz, Ressourcenerschöpfung und lösen Benachrichtigungen oder automatische Failover-Prozeduren aus.
Sichern und Wiederherstellen: Sicherungen können verwendet werden, um Datenbanken bei Datenbeschädigung oder schwerwiegenden Ausfällen in einem früheren Zustand wiederherzustellen.
Verbindungs-Pooling (optional): Optimiert die Leistung und Skalierbarkeit von Anwendungen, die mit Ihren Datenbanken interagieren.
Tools für Hochverfügbarkeit
Patroni ist ein Open-Source-Tool zur Clusterverwaltung für PostgreSQL-Datenbanken, das für die Verwaltung und Automatisierung der Hochverfügbarkeit von PostgreSQL-Clustern entwickelt wurde. Patroni verwendet verschiedene verteilte Konsenssysteme wie etcd, Consul oder Zookeeper, um den Clusterstatus zu koordinieren und zu verwalten. Zu den wichtigsten Funktionen und Komponenten von Patroni gehören Hochverfügbarkeit mit automatischem Failover, Leader-Auswahl, Replikation und Wiederherstellung. Patroni wird zusammen mit dem PostgreSQL-Dienst auf Datenbankserverinstanzen ausgeführt und verwaltet deren Status, Failover und Replikation, um eine hohe Verfügbarkeit und Zuverlässigkeit zu gewährleisten.
Patroni verwendet ein verteiltes Konsenssystem, um Metadaten zu speichern und den Cluster zu verwalten. In dieser Anleitung verwenden wir einen verteilten Konfigurationsspeicher (Distributed Configuration Store, DCS) namens etcd. etcd wird unter anderem zum Speichern und Abrufen von Informationen zu verteilten Systemen wie Konfiguration, Integrität und aktuellem Status verwendet, um eine konsistente Konfiguration auf allen Knoten zu gewährleisten.
High Availability Proxy (HAProxy) ist eine Open-Source-Software, die für das Load-Balancing und das Proxying von TCP- und HTTP-basierten Anwendungen verwendet wird. Sie dient dazu, die Leistung und Zuverlässigkeit von Webanwendungen zu verbessern, indem eingehende Anfragen auf mehrere Server verteilt werden. HAProxy bietet Load-Balancing, indem es den Netzwerkverkehr auf mehrere Server verteilt. HAProxy führt auch Systemdiagnosen durch, um den Status der Backend-Server zu ermitteln, mit denen es eine Verbindung herstellt. Wenn ein Server eine Systemdiagnose nicht besteht, sendet HAProxy keinen Traffic mehr an den Server, bis er die Systemdiagnosen wieder besteht.
Überlegungen zur synchronen und asynchronen Replikation
In einem von Patroni verwalteten PostgreSQL-Cluster kann die Replikation sowohl im synchronen als auch im asynchronen Modus konfiguriert werden. Standardmäßig verwendet Patroni die asynchrone Streaming-Replikation. Bei strengen RPO-Anforderungen empfehlen wir die Verwendung der synchronen Replikation.
Die synchrone Replikation in PostgreSQL sorgt für Datenkonsistenz, indem vor dem Commit gewartet wird, bis Transaktionen sowohl in die primäre Datenbank als auch in mindestens eine synchrone Standby-Datenbank geschrieben wurden. Die synchrone Replikation sorgt dafür, dass bei einem Ausfall des primären Systems keine Daten verloren gehen. So wird eine hohe Datenbeständigkeit und ‑konsistenz erreicht. Der primäre Server wartet auf Bestätigungen vom synchronen Standby-Server, was aufgrund der zusätzlichen Roundtrip-Zeit zu einer höheren Latenz und einem potenziell geringeren Durchsatz führen kann. Dies kann den Gesamtdurchsatz des Systems verringern, insbesondere bei hoher Last.
Bei der asynchronen Replikation können Transaktionen im primären Cluster committet werden, ohne dass auf Bestätigungen von Standby-Clustern gewartet werden muss. Der primäre Knoten sendet WAL-Datensätze an Standby-Knoten, die sie asynchron anwenden. Dieser asynchrone Ansatz reduziert die Schreiblatenz und verbessert die Leistung, birgt aber das Risiko von Datenverlusten, wenn die primäre Instanz ausfällt, bevor die Standby-Instanz aufgeholt hat. Standby-Instanzen können hinter der primären Instanz zurückbleiben, was bei einem Failover zu potenziellen Inkonsistenzen führen kann.
Die Wahl zwischen synchroner und asynchroner Replikation in einem Patroni-Cluster hängt von den spezifischen Anforderungen an Datenbeständigkeit, Konsistenz und Leistung ab. Die synchrone Replikation ist in Szenarien vorzuziehen, in denen Datenintegrität und minimaler Datenverlust entscheidend sind, während die asynchrone Replikation für Umgebungen geeignet ist, in denen Leistung und geringere Latenz priorisiert werden. Sie können eine gemischte Lösung konfigurieren, die einen Cluster mit drei Knoten mit einem synchronen Standby in derselben Region, aber einer anderen nahegelegenen Zone oder einem anderen Rechenzentrum und einem zweiten asynchronen Standby in einer anderen Region oder einem weiter entfernten Rechenzentrum umfasst, um sich vor potenziellen regionalen Ausfällen zu schützen.