Auf dieser Seite werden Hochverfügbarkeit und die von uns empfohlenen Tools beschrieben.
Ausfallsicherheit von Daten
Sie können sich die Datenausfallsicherheit in Bezug auf Verfügbarkeit, Zeit zur Wiederherstellung des Dienstes und Datenverlust vorstellen. Die Verfügbarkeit wird in der Regel in Form der Uptime gemessen und als Prozentsatz der Zeit angegeben, 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 bis zur Dienstwiederherstellung nach einem Ausfall wird als Recovery Time Objective (RTO) bezeichnet. Der akzeptable Datenverlust aufgrund eines Ausfalls wird als Recovery Point Objective (RPO) bezeichnet und als Zeitraum ausgedrückt, in dem Transaktionen verloren gehen. Ein RPO von 10 Minuten bedeutet beispielsweise, dass bei einem Ausfall Daten von bis zu 10 Minuten verloren gehen können.
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 außerdem eine RPO von 0, keine Datenverluste bei einem Ausfall und eine RTO von 30 Sekunden verlangen. Für eine andere Arbeitslast können Sie den SLO auf 99,9%, den RPO auf 5 Minuten und den RTO auf 10 Minuten festlegen.
Mit Datenbanksicherungen können Sie eine grundlegende Datenbankausfallsicherheit implementieren. AlloyDB Omni unterstützt Sicherungen mit pgBackRest und archiviert die WAL-Dateien (Write-Ahead Log) der Datenbank, um Datenverluste zu minimieren. Bei diesem Ansatz kann die primäre Datenbank bei einem Ausfall aus einer Sicherung mit einem RPO von Minuten und einer RTO von Minuten bis Stunden wiederhergestellt werden, je nach Größe der Datenbank.
Bei strengeren RPO- und RTO-Anforderungen können Sie AlloyDB Omni mit Patroni in einer Hochverfügbarkeitskonfiguration einrichten. Bei 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-Streaming-Replikation verwendet wird, damit jede Transaktion, die auf der primären Datenbank verbindlich wird, synchron in beiden Standby-Datenbanken repliziert wird. Dies führt bei den meisten Ausfallszenarien zu einem RPO von null und einer RTO von weniger als 60 Sekunden.
Je nach Clusterkonfiguration kann die synchrone Replikation die Reaktionszeit für Transaktionen beeinträchtigen. Sie können auch ein gewisses Risiko für Datenverluste eingehen. Sie können beispielsweise einen RPO von Null haben, wenn Sie eine niedrigere Transaktionslatenz im Austausch für eine höhere Verfügbarkeit mit asynchroner Replikation statt synchroner Replikation implementieren. Aufgrund der potenziellen Auswirkungen der synchronen Replikation auf die Transaktionslatenz werden Hochverfügbarkeitsarchitekturen fast immer innerhalb eines einzelnen Rechenzentrums oder zwischen Rechenzentren implementiert, die sich in der Nähe befinden (einige Kilometer voneinander entfernt, mit einer Latenz von weniger als 10 Millisekunden). In dieser Dokumentation wird jedoch standardmäßig die synchrone Replikation verwendet.
Für die Notfallwiederherstellung, also den Schutz vor dem Verlust eines Rechenzentrums oder einer Region mit mehreren Rechenzentren in der Nähe, kann AlloyDB Omni mit einer asynchronen Streaming-Replikation 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 voneinander entfernt sind. In dieser Konfiguration ist die primäre Region mit der synchronen Streamingreplikation zwischen der primären und der Standby-Datenbank innerhalb der Region konfiguriert. Außerdem ist die asynchrone Streamingreplikation von der primären Region zu einer oder mehreren sekundären Regionen konfiguriert. AlloyDB Omni kann in der sekundären Region mit mehreren Datenbankinstanzen konfiguriert werden, damit es sofort nach einem Failover von der primären Region geschützt ist.
Funktionsweise der Hochverfügbarkeit
Die spezifischen Verfahren und Tools, die zur Implementierung der 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 einer hohen Verfügbarkeit für Datenbanken verwendet werden. Sie 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.
Automatischer 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 Schutzmaßnahmen implementiert, um die Datenintegrität bei Ausfällen zu schützen. Dazu gehören Replikationstechniken und Prüfungen der Dateneinheitlichkeit.
Clustering: Beim Clustering werden mehrere Datenbankserver gruppiert, um als einzelnes System zusammenzuarbeiten. So sind alle Knoten im Cluster aktiv und verarbeiten Anfragen, was Load Balancing und Redundanz ermöglicht.
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 ein erhöhter Traffic wird besser verarbeitet.
Monitoring und Benachrichtigungen: Monitoring-Tools erkennen Probleme wie Serverausfälle, hohe Latenz, Ressourcenausschöpfung und lösen Benachrichtigungen oder automatische Failover-Vorgänge aus.
Sicherung und Wiederherstellung: Mithilfe von Sicherungen können Datenbanken bei Datenbeschädigungen oder schwerwiegenden Ausfällen in einen früheren Zustand wiederhergestellt werden.
Verbindungspool (optional): Optimiert die Leistung und Skalierbarkeit von Anwendungen, die mit Ihren Datenbanken interagieren.
Hochverfügbarkeitstools
Patroni ist ein Open-Source-Clusterverwaltungstool für PostgreSQL-Datenbanken, das die Hochverfügbarkeit von PostgreSQL-Clustern verwalten und automatisieren soll. 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-Wahl, 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 diesem Leitfaden verwenden wir einen verteilten Konfigurationsspeicher (Distributed Configuration Store, DCS) namens etcd. Eine der Verwendungen von etcd besteht darin, Informationen zu verteilten Systemen wie Konfiguration, Gesundheit und aktuellen Status zu speichern und abzurufen, 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 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 der Netzwerkverkehr auf mehrere Server verteilt wird. HAProxy überwacht außerdem den Status der Backend-Server, zu denen eine Verbindung hergestellt wird, indem Systemdiagnosen durchgeführt werden. Wenn ein Server eine Systemdiagnose nicht besteht, sendet HAProxy keinen Traffic mehr an ihn, 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 darauf gewartet wird, dass Transaktionen sowohl in die primäre Datenbank als auch in mindestens eine synchrone Standby-Datenbank geschrieben werden, bevor sie bestätigt werden. Die synchrone Replikation sorgt dafür, dass Daten bei einem primären Ausfall nicht verloren gehen. So wird eine hohe Datenausfallsicherheit und Konsistenz gewährleistet. Das primäre System wartet auf Bestätigungen vom synchronen Standby, was aufgrund der zusätzlichen Rücklaufzeit zu einer höheren Latenz und einem potenziell geringeren Durchsatz führen kann. Dies kann den Gesamtdurchsatz des Systems verringern, insbesondere bei hoher Auslastung.
Bei der asynchronen Replikation können Transaktionen im primären Cluster verbindlich festgelegt werden, ohne auf Bestätigungen von Standby-Clustern zu warten. Das primäre Replikat sendet WAL-Einträge an Standby-Replikate, die sie asynchron anwenden. Dieser asynchrone Ansatz reduziert die Schreiblatenz und verbessert die Leistung, birgt aber das Risiko von Datenverlusten, wenn der primäre Server ausfällt, bevor der Standby-Server auf dem neuesten Stand ist. Standbys können hinter dem primären System zurückliegen, was zu potenziellen Inkonsistenzen beim Failover führen kann.
Die Wahl zwischen synchroner und asynchroner Replikation in einem Patroni-Cluster hängt von den spezifischen Anforderungen an die 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 dagegen 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 einem synchronen Standby in derselben Region, aber in einer anderen Zone oder einem anderen Rechenzentrum in der Nähe 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.