Daten mit zonaler Replikation schützen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird die Referenzarchitektur für die erweiterte Verfügbarkeit von AlloyDB Omni beschrieben, die Hochverfügbarkeit durch die Bereitstellung von einem oder mehreren Datenbankreplikaten innerhalb derselben Region bietet und vor Fehlern auf Knoten- oder Zonenebene schützt.

Anwendungsfälle

Diese Referenzarchitektur für die Verfügbarkeit eignet sich für die folgenden Anwendungsfälle:

  • Geschäftskritische Anwendungen, die niedrigere RTO und RPO erfordern.
  • Sie möchten ein Replikat in einer anderen Zone oder auf einem anderen Knoten bereitstellen, um Hochverfügbarkeit für Ihre Datenbanken zu erreichen und vor Instanz-, Server- und Zonenausfällen zu schützen.
  • Sie möchten sich vor Nutzerfehlern und Datenbeschädigung schützen (mithilfe von Back-ups).

Funktionsweise der Referenzarchitektur

Die erweiterte Verfügbarkeit ergänzt die Standardverfügbarkeit durch das Hinzufügen von Read-Replica-Instanzen in der Region, um eine hohe Verfügbarkeit (HA) zu ermöglichen, die das Recovery Time Objective (RTO) reduziert. Dieser Ansatz reduziert auch das Recovery Point Objective (RPO), da transaktionale Änderungen an das Replikat gestreamt werden können.

Für die Hochverfügbarkeit in AlloyDB Omni werden mindestens zwei Datenbankinstanzen verwendet. Eine Instanz fungiert als primäre Datenbank und unterstützt Lese- und Schreibvorgänge. Die verbleibenden Instanzen dienen als Lesereplikate und werden im Lesemodus ausgeführt.

Im Folgenden finden Sie wichtige HA-Konzepte:

  • Failover ist das Verfahren bei einem ungeplanten Ausfall, bei dem die primäre Instanz ausfällt oder nicht mehr verfügbar ist und das Standby-Replikat aktiviert wird, um den primären (Lese-/Schreib-)Modus zu übernehmen. Dieser Vorgang wird als Promotion bezeichnet. Wenn der primäre Server oder die primäre Datenbank in diesen Szenarien wieder online ist, muss die Datenbank in der Regel neu erstellt werden und dann als Standby-Datenbank fungieren. Um eine hohe Verfügbarkeit zu gewährleisten, sind Mechanismen vorhanden, die Failovers automatisch ausführen.
  • Ein Switchover, auch Rollenumkehr genannt, ist ein Verfahren, mit dem die Modi zwischen der primären Datenbank und einer der Standby-Datenbanken gewechselt werden. Die primäre Datenbank wird zur Standby-Datenbank und die Standby-Datenbank zur primären Datenbank. Switchovers erfolgen in der Regel kontrolliert und reibungslos. Sie können aus verschiedenen Gründen initiiert werden, z. B. um Ausfallzeiten und Patches der bisherigen primären Datenbank zu ermöglichen. Bei reibungslosen Switchovers muss ein zukünftiges Zurückschalten möglich sein, ohne dass der neue Standby oder andere Aspekte der Replikationskonfiguration neu instanziiert werden müssen.

Optionen für Hochverfügbarkeit

Zur Unterstützung von HA können Sie AlloyDB Omni auf folgende Weise bereitstellen:

Hinweis: Patroni und HAProxy sind nicht kommerzielle Drittanbietertools, die mit AlloyDB Omni kompatibel sind.

Wir empfehlen, mindestens zwei Standby-Datenbanken zu haben, damit der Verlust einer Datenbank die hohe Verfügbarkeit des Clusters nicht beeinträchtigt. In diesem Modus haben Sie im Falle eines Failovers oder während einer geplanten Wartung eines Knotens mindestens ein HA-Paar.

Informationen zur Planung der Größe und Form Ihrer AlloyDB Omni-Bereitstellung finden Sie unter AlloyDB Omni-Installation auf einer VM planen.

Load-Balancer

Ein weiterer wichtiger Mechanismus, der einen reibungsloseren Switchover und Failover ermöglicht, ist das Vorhandensein eines Load Balancers. Bei Nicht-Kubernetes-Bereitstellungen bietet die HAProxy-Software Load-Balancing. 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 ihn, bis er die Systemdiagnosen wieder besteht.

Der Kubernetes-Operator stellt einen eigenen Load-Balancer bereit, der sich ähnlich verhält. Er erstellt einen Dienst für die Datenbank, der auf den Load-Balancer verweist, um dies für den Nutzer transparent zu machen.

Hochverfügbarkeit

Die in einer Region bereitgestellten Lesereplikat-Datenbanken bieten Hochverfügbarkeit, falls die primäre Datenbank ausfällt. Wenn die primäre Datenbank ausfällt, wird die Standby-Datenbank hochgestuft, um die primäre Datenbank zu ersetzen. Die Anwendung wird dann mit wenig oder gar keiner Unterbrechung fortgesetzt.

Es empfiehlt sich, regelmäßig (jährlich oder halbjährlich) Switchovers durchzuführen, um sicherzustellen, dass alle Anwendungen, die auf diese Datenbanken angewiesen sind, weiterhin innerhalb eines angemessenen Zeitrahmens eine Verbindung herstellen und reagieren können.

Der Schutz auf Zonenebene kann mit beiden Bereitstellungstypen erreicht werden, indem eines der Standby-Lesereplikate in einer anderen Verfügbarkeitszone als die primäre Datenbank platziert wird.

Ein weiterer Vorteil von Lesereplikaten ist die Möglichkeit, schreibgeschützte Vorgänge auf die Standby-Datenbanken auszulagern, die als Berichtsdatenbanken mit aktuellen Daten fungieren können. Dieser Ansatz reduziert die Last und den Aufwand für den primären Lese-/Schreibserver.

Sicherungen und Konfiguration für hohe Verfügbarkeit

Lesereplikate können in mehreren Zonen eingerichtet werden, die Hochverfügbarkeit bieten. Sie bieten zwar einen niedrigen RTO und RPO, schützen aber nicht vor bestimmten Ausfällen wie logischer Datenbeschädigung, z. B. versehentlichem Löschen von Tabellen oder falschen Datenaktualisierungen. Daher sind zusätzlich zur HA-Einrichtung regelmäßige Sicherungen erforderlich. Weitere Informationen finden Sie in der Dokumentation zur Standard-Verfügbarkeitsarchitektur.

Abbildung 1 zeigt eine empfohlene HA-Konfiguration mit zwei Read-Replica-Standbydatenbanken in zwei verschiedenen Verfügbarkeitszonen.

AlloyDB Omni mit Optionen für Sicherungen und Hochverfügbarkeit

Abbildung 1. AlloyDB Omni mit Optionen für Sicherungen und Hochverfügbarkeit.

Um Datenverlust zu vermeiden, wenn die primäre Instanz ausfällt, ist es erforderlich, die Replikation im synchronen Modus zu konfigurieren. Diese Methode bietet zwar einen hohen Datenschutz, kann sich aber auf die Leistung der primären Datenbank auswirken, da alle Commits sowohl in die primäre als auch in alle synchronisierten Standby-Datenbanken geschrieben werden müssen. Eine Netzwerkverbindung mit geringer Latenz zwischen diesen Datenbankinstanzen ist für diese Einrichtung entscheidend.

Kubernetes-HA-Deployments

Bei Kubernetes-Bereitstellungen können Sie durch einige grundlegende Änderungen und Ergänzungen an Ihrer AlloyDB Omni-Bereitstellungsdatei Failover-Standby- oder Lesereplikate hinzufügen, um den Ausfall der primären Datenbank zu ermöglichen. Ein Failover-Standby und ein schreibgeschütztes Replikat können konfiguriert werden. Der Betreiber kümmert sich um die Bereitstellung und Veröffentlichung des Dienstes. Der Operator automatisiert auch viele der HA-Prozesse, z. B. das Neuerstellen von Standby-Datenbanken nach einem Failover und die Verwendung der in die AlloyDB Omni Kubernetes-Engine integrierten Reparaturmechanismen.

Bei einer Kubernetes-Bereitstellung profitieren die Verfügbarkeit von Infrastruktur und Anwendungen von integrierten Kubernetes-Funktionen, die sich um Knoten- und Pod-Fehler kümmern, darunter:

Zusätzlich zum integrierten Schutz stellt der Operator die folgenden Parameter zur Verfügung, um die Erkennung eines fehlgeschlagenen primären oder Standby-Servers zu beeinflussen:

  • healthcheckPeriodSeconds: Die Zeit zwischen den Systemdiagnosen. Der Standardwert beträgt 30 Sekunden.
  • autoFailoverTriggerThreshold: Die Anzahl der aufeinanderfolgenden fehlgeschlagenen Health Checks, bevor ein Failover eingeleitet wird. Der Standardwert ist 3.

Weitere Informationen finden Sie unter Hochverfügbarkeit in Kubernetes verwalten.

HA-Bereitstellungen ohne Kubernetes

Die eigenständige Bereitstellung ohne Kubernetes ist eine manuelle Konfiguration, für die Drittanbietertools erforderlich sind. Die Einrichtung und Wartung ist komplexer als bei der Kubernetes-Bereitstellung.

Wenn Sie eine Nicht-Kubernetes-Bereitstellung verwenden, gibt es einige Parameter, die sich darauf auswirken, wie ein Failover erkannt wird und wie schnell ein Failover erfolgt, nachdem der primäre Server nicht mehr verfügbar ist. Im Folgenden finden Sie eine kurze Zusammenfassung dieser Parameter:

  • Ttl: die maximale Zeit, die zum Erwerben einer Sperre für die primäre Datenbank vor dem Initiieren eines Failovers benötigt wird. Der Standardwert ist 30 Sekunden.
  • Loop_wait: Die Wartezeit, bevor die Prüfung wiederholt wird. Der Standardwert beträgt 10 Sekunden.
  • Retry_timeout: Das Zeitlimit, bevor die primäre Instanz aufgrund eines Netzwerkfehlers herabgestuft wird. Der Standardwert beträgt 10 Sekunden.

Weitere Informationen finden Sie unter Hochverfügbarkeitsarchitektur für AlloyDB Omni for PostgreSQL.

Implementierung

Wenn Sie eine Referenzarchitektur für die Verfügbarkeit auswählen, sollten Sie die folgenden Vorteile, Einschränkungen und Alternativen berücksichtigen.

Vorteile

  • Schützt vor Instanzfehlern.
  • Schutz vor Serverfehlern.
  • Schützt vor Zonenausfällen.
  • Die RTO ist im Vergleich zu Standard Availability deutlich kürzer.

Beschränkungen

  • Kein zusätzlicher Schutz vor regionalen Katastrophen.
  • Mögliche Auswirkungen der synchronen Replikation auf die Leistung des primären Knotens.
  • Wenn Sie das PostgreSQL-WAL-Streaming im synchronen Modus konfigurieren, kommt es bei normalem Betrieb oder typischen Failovers zu keinem Datenverlust (RPO=0). Dieser Ansatz schützt jedoch nicht vor Datenverlust in bestimmten Situationen mit doppelten Fehlern, z. B. wenn alle Standby-Instanzen verloren gehen oder von der primären Instanz aus nicht mehr erreichbar sind und dies unmittelbar von einem Neustart der primären Instanz gefolgt wird.

Alternativen

Nächste Schritte