Daten mit zonaler und regionaler Replikation schützen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird die Referenzarchitektur für die Premium-Verfügbarkeit von AlloyDB Omni beschrieben. Sie umfasst den Datenschutz durch zonale Replikation in einer Region (Hochverfügbarkeit) und bietet zusätzlichen Schutz für die Notfallwiederherstellung (Disaster Recovery, DR) durch asynchrones Streaming über große geografische Grenzen hinweg.

Diese Referenzarchitektur eignet sich am besten für die folgenden Anwendungsfälle:

  • Sie benötigen zusätzlich zum zonenbasierten Schutz auch einen regionalen Schutz für Ihre unternehmenskritischen Anwendungen.

Diese Referenzarchitektur für die Verfügbarkeit umfasst Lesereplikate innerhalb der Region für Hochverfügbarkeit und regionsübergreifend für die Notfallwiederherstellung. Diese multiregionale Bereitstellung schützt vor erheblichen Störungen, einschließlich weitverbreiteter Stromausfälle und großflächiger Naturkatastrophen.

Überlegungen zur Referenzarchitektur für Verfügbarkeit

Berücksichtigen Sie bei der Bewertung dieser Referenzarchitektur für Verfügbarkeit die folgenden Faktoren:

  • Netzwerklatenz und ‑bandbreite innerhalb der Region und über Regionen hinweg
  • Geografische Platzierung von Datenbanken und Anwendungsservern
  • Strategie zum Auslagern schreibgeschützter Arbeitslasten auf Replikate
  • Hochverfügbarkeit in der Remote-DR-Region bereitstellen

Ein schreibgeschützter Lastenausgleich kann erforderlich sein, insbesondere wenn Sie regionale Anwendungsserver verwenden, damit Anfragen zur schnellsten Antwort an die nächstgelegene Datenbank weitergeleitet werden. Weitere Informationen finden Sie unter Anfragerouting für einen multiregionalen klassischen Application Load Balancer.

Für die regionsübergreifende Replikation ist möglicherweise zusätzliches Monitoring erforderlich, um sicherzustellen, dass die Replikationsverzögerung aufgrund von Transaktionslast oder Netzwerkkapazität nicht zunimmt.

Damit die Notfallwiederherstellung erfolgreich ist, müssen Sie gründliche Tests durchführen. Es ist wichtig, die Anwendungsfunktionen und den Durchsatz zu testen, wenn zwischen Anwendungsservern und der Datenbank Netzwerkverbindungen mit hoher Latenz bestehen.

HA-Architekturen in der Region und DR-Architekturen für mehrere Regionen

Abbildung 1 zeigt eine vorgeschlagene HA- und DR-Konfiguration mit drei Read-Replica-Standby-Datenbanken in drei Verfügbarkeitszonen und zwei Regionen.

AlloyDB Omni mit Sicherungen und regionenübergreifenden Hochverfügbarkeitsoptionen

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

Wie in Abbildung 1 dargestellt, bietet die synchrone Streamingreplikation auf lokale Replikate (innerhalb derselben Region) Hochverfügbarkeit, während die asynchrone Streamingreplikation auf ein geografisch getrenntes Remote-Replikat Schutz vor regionalen Katastrophen bietet. In der gesamten Konfiguration kann nur die primäre Instanz Lese-/Schreibvorgänge ausführen, während die anderen Replikate Leseanfragen bearbeiten können.

Konfigurieren Sie die Replikation von der primären Instanz zu Replikaten in der Region im synchronen Modus, während die Replikation zu regionenübergreifenden Replikaten im asynchronen Modus konfiguriert werden muss, um zu vermeiden, dass die Latenz die primäre Schreibleistung beeinträchtigt. Bei einem regionalen Ausfall kann diese Konfiguration zu einem RPO ungleich null führen. Diese Einrichtung ermöglicht jedoch ein schnelleres RTO im Falle eines Fehlers. Das liegt daran, dass die primäre Datenbank nicht auf die Bestätigung von Remote-Standby-Datenbanken warten muss, bevor Transaktionen committet werden.

Es ist möglich, zusätzliche regionenübergreifende Sicherungen von den Read-Replica-Datenbanken zu erstellen und so die Redundanz der Sicherungen zu erhöhen, die von der primären Datenbank erstellt werden.

Sicherungen von Lesereplikaten

Wenn Sie Kubernetes-Bereitstellungen verwenden, wird die sekundäre Bereitstellung in der alternativen Region automatisch mit zusätzlichen Back-ups eingerichtet. Wenn Sie keine Kubernetes-Deployments verwenden, können Sie Back-ups nach Bedarf bereitstellen. Berücksichtige Folgendes:

  • Wenn Ihre Remote-Sicherung anfällig für regionale Ausfälle ist, müssen Sie zusätzliche Sicherungen in den alternativen Regionen starten.
  • Wenn Sie eine Sicherungsredundanz benötigen, müssen Sie regionale Lesereplikat-Sicherungen erstellen.

Standort des Lesereplikats zur Unterstützung der Verfügbarkeit in mehreren Zonen

In Nicht-Kubernetes-Bereitstellungen können Sie bestimmte Lesereplikate auswählen, die im Falle eines primären Fehlers die Rolle des primären Knotens übernehmen sollen. Der AlloyDB Omni Kubernetes-Operator übernimmt automatisch die Knotenplatzierung in Zonen und die Knoten, auf denen die Pods bereitgestellt werden sollen. Einige Konfigurationsoptionen, die sich auf die Platzierung auswirken, z. B. Pod-Affinität und ‑Toleranz, sind in der Datenbankkonfiguration verfügbar, die für die Bereitstellung mit dem AlloyDB Omni-Operator verwendet wird.

Migration von einer reinen HA- zu einer HA- und DR-Architektur

Bei Nicht-Kubernetes-Bereitstellungen müssen Sie einen neuen Standby in einer neuen Region erstellen und diese Konfiguration der Patroni-Clusterkonfiguration hinzufügen. Für Kubernetes-Bereitstellungen müssen Sie eine neue regionale Kubernetes-Bereitstellung erstellen, die als sekundärer Datenbankcluster bezeichnet wird, und die datenzentrumübergreifende Replikation aktivieren.

Implementierung

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

Vorteile

  • Schutz vor zonalen und Instanzfehlern
  • Schutz vor regionalen Ausfällen
  • RTO wird reduziert, wenn in der Datenbank ein regionaler Fehler auftritt

Beschränkungen

  • Sie können den RPO für die regionale Wiederherstellung mit synchroner Replikation reduzieren. Dieser Ansatz führt jedoch zu einer zusätzlichen Latenz bei der Transaktionsleistung. Für die Notfallwiederherstellung und die Replikation in einer Remote-Region empfehlen wir, nur die asynchrone Replikation zu verwenden.
  • 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.

Datenschutzoptionen

Nächste Schritte