Auf dieser Seite werden Hochverfügbarkeit und die Tools beschrieben, die wir empfehlen. Diese Tools unterstützen auch die Einrichtung von Hochverfügbarkeit für Cluster, für die die transparente Datenverschlüsselung (Transparent Data Encryption, TDE) aktiviert ist.
Datenresilienz
Sie können die Datenresilienz in Bezug auf Verfügbarkeit, Zeit bis zur Wiederherstellung des Dienstes und Datenverlust betrachten. Die Verfügbarkeit wird in der Regel in Bezug auf die Betriebszeit gemessen und als Prozentsatz der Zeit ausgedrückt, in der die Datenbank verfügbar ist. Um beispielsweise eine Verfügbarkeit von 99,99% zu erreichen, darf Ihre Datenbank nicht länger als 52,6 Minuten pro Jahr oder 4,38 Minuten pro Monat ausfallen. Die Zeit, die für die Wiederherstellung des Dienstes nach einem Ausfall benötigt wird, wird als Recovery Time Objective (RTO) bezeichnet. Die Menge des akzeptablen Datenverlusts aufgrund eines Ausfalls wird als Recovery Point Objective (RPO) bezeichnet und als die Zeit ausgedrückt, für die Transaktionen verloren gehen. Ein RPO von 10 Minuten bedeutet beispielsweise, dass Sie im Falle eines Ausfalls Daten im Wert von bis zu 10 Minuten 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 beispielsweise das SLO auf 99,99 % festlegen und auch ein RPO von 0, keinen Datenverlust bei einem Ausfall und ein RTO von 30 Sekunden festlegen. Für eine andere Arbeitslast können Sie das SLO auf 99,9%, das RPO auf 5 Minuten und das RTO auf 10 Minuten festlegen.
Sie können eine grundlegende Datenbankresilienz mit Datenbanksicherungen implementieren. AlloyDB Omni unterstützt Sicherungen mit pgBackRest und archiviert auch die Write Ahead Log (WAL)-Dateien 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 Patronieinrichten. 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, um sicherzustellen, dass jede Transaktion, die auf der primären Datenbank festgelegt wird, synchron auf beide Standby-Datenbanken repliziert wird. Dies bietet ein RPO von null und ein RTO von weniger als 60 Sekunden für die meisten Ausfallszenarien.
Je nach Clusterkonfiguration kann sich die synchrone Replikation auf die Antwortzeit für Transaktionen auswirken. Sie können auch einen geringen Datenverlust riskieren. Sie können beispielsweise ein RPO ungleich null haben, um die Transaktionslatenz zu verringern, indem Sie Hochverfügbarkeit mit asynchroner Replikation anstelle von synchroner Replikation implementieren. Aufgrund der potenziellen Auswirkungen der synchronen Replikation auf die Transaktionslatenz werden Hochverfügbarkeitsarchitekturen fast immer in einem einzigen Rechenzentrum oder zwischen Rechenzentren implementiert, die nah beieinander liegen (einige Dutzend Kilometer entfernt oder mit einer Latenz von weniger als 10 Millisekunden). In dieser Dokumentation wird jedoch die synchrone Replikation als Standard verwendet.
Für die Notfallwiederherstellung, die den Schutz vor dem Verlust eines Rechenzentrums oder einer Region mit mehreren Rechenzentren in der Nähe umfasst, kann AlloyDB Omni mit asynchroner Streamingreplikation von der primären Region zu einer sekundären Region konfiguriert werden, die in der Regel Hunderte oder Tausende von Kilometern entfernt ist oder eine Latenz von 10 bis 100 Millisekunden aufweist. In dieser Konfiguration ist die primäre Region mit synchroner Streamingreplikation zwischen der primären und der Standby-Datenbank innerhalb der Region konfiguriert. Die asynchrone Streamingreplikation ist von der primären Region zu einer oder mehreren sekundären Regionen konfiguriert. AlloyDB Omni kann in der sekundären Region mit mehreren Datenbankknoten konfiguriert werden, um sicherzustellen, dass sie sofort nach einem Failover von der primären Region geschützt ist.
Funktionsweise von 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 in der Regel bei der Implementierung von Hochverfügbarkeit für Datenbanken verwendet werden. Sie können je nach Datenbankverwaltungssystem variieren:
Redundanz: Durch die Replikation Ihrer Datenbank auf mehreren Servern oder in mehreren geografischen Regionen stehen Failover-Optionen zur Verfügung, wenn eine primäre Instanz ausfällt.
Automatisches Failover: Ein Mechanismus zum Erkennen von Fehlern und zum 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, um als ein einziges System zusammenzuarbeiten. Ein primärer Knoten verarbeitet Lese-/Schreib-Traffic, während Standby-Knoten Daten kontinuierlich replizieren, um Failover-Redundanz zu bieten und die Leseskalierbarkeit zu unterstützen.
Fallback: Methoden, um auf die ursprüngliche Architektur zurückzugreifen. 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, Ressourcenüberlastung und lösen Benachrichtigungen oder automatische Failover-Prozeduren aus.
Sicherung und Wiederherstellung: Mit Sicherungen können Datenbanken im Falle von Datenbeschädigung oder katastrophalen Ausfällen in einen früheren Zustand zurückversetzt werden.
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, mit dem die Hochverfügbarkeit für PostgreSQL-Cluster verwaltet und automatisiert werden kann. Patroni verwendet verschiedene verteilte Konsens systeme wie etcd, Consul oder Zookeeper, um den Cluster status zu koordinieren und zu verwalten. Zu den wichtigsten Funktionen und Komponenten von Patroni gehören Hochverfügbarkeit mit automatischem Failover, Leader-Wahl, Replikation und Wiederherstellung. Patroni wird neben dem PostgreSQL-Dienst auf Datenbankserverinstanzen ausgeführt und verwaltet deren Status, Failover und Replikation, um Hochverfü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 Distributed Configuration Store (DCS) namens etcd. Einer der Anwendungsfälle von etcd ist das Speichern und Abrufen von Informationen zu verteilten Systemen wie Konfiguration, Status und aktueller Status, um eine konsistente Konfiguration auf allen Knoten zu gewährleisten.
High Availability Proxy (HAProxy) ist eine Open-Source- Software, die für Load-Balancing und Proxying von TCP- und HTTP-basierten Anwendungen verwendet wird. Sie verbessert die Leistung und Zuverlässigkeit von Webanwendungen, indem sie den Netzwerkverkehr auf mehrere Server verteilt. HAProxy verwaltet auch den Status der Backend-Server, mit denen es verbunden ist, indem es Systemdiagnosen durchführt. Wenn ein Server eine Systemdiagnose nicht besteht, sendet HAProxy keinen Traffic mehr an diesen 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 Streamingreplikation. Bei strengen RPO-Anforderungen empfehlen wir die Verwendung der synchronen Replikation.
Die synchrone Replikation in PostgreSQL sorgt für Datenkonsistenz, indem gewartet wird, bis Transaktionen sowohl in die primäre als auch in mindestens eine synchrone Standby-Instanz geschrieben wurden, bevor ein Commit ausgeführt wird. Die synchrone Replikation sorgt dafür, dass Daten im Falle eines Ausfalls der primären Instanz nicht verloren gehen. Sie bietet eine hohe Datenbeständigkeit und -konsistenz. Die primäre Instanz wartet auf Bestätigungen von der synchronen Standby-Instanz, was aufgrund der zusätzlichen Umlaufzeit zu einer höheren Latenz und möglicherweise zu einem geringeren Durchsatz führen kann. Dies kann den Gesamtdurchsatz des Systems verringern, insbesondere bei hoher Last.
Bei der asynchronen Replikation können Transaktionen auf dem primären Knoten festgelegt werden, ohne auf Bestätigungen von Standby-Knoten zu warten. Die primäre Instanz sendet WAL-Einträge an Standby-Instanzen, die sie asynchron anwenden. Dieser asynchrone Ansatz reduziert die Schreiblatenz und verbessert die Leistung, birgt jedoch das Risiko eines Datenverlusts, 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. Die asynchrone Replikation eignet sich für Umgebungen, in denen Leistung und geringere Latenz priorisiert werden. Sie können eine gemischte Lösung konfigurieren, die einen Cluster mit drei Knoten mit einer synchronen Standby-Instanz in derselben Region, aber in einer anderen nahe gelegenen Zone oder einem anderen Rechenzentrum und einer zweiten asynchronen Standby-Instanz in einer anderen Region oder einem weiter entfernten Rechenzentrum umfasst, um sich vor potenziellen regionalen Ausfällen zu schützen.