Übersicht über die Referenzarchitektur für die Verfügbarkeit von AlloyDB Omni

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite werden die AlloyDB Omni-Verfügbarkeitsarchitekturen vorgestellt, mit denen Sie dafür sorgen können, dass Ihre AlloyDB Omni-Datenbank zeitnah und mit geringem oder gar keinem Datenverlust wiederhergestellt werden kann.

Um die Geschäftskontinuität zu gewährleisten und Datenverluste zu minimieren, sind Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) entscheidende Datenschutzstrategien für AlloyDB Omni. Bei der Hochverfügbarkeit geht es darum, die Datenbankverfügbarkeit aufrechtzuerhalten und das Recovery Time Objective (RTO) zu minimieren. Bei der Notfallwiederherstellung geht es darum, die Wiederherstellung nach katastrophalen Ereignissen zu ermöglichen und das Recovery Point Objective (RPO) zu minimieren.

RTO und RPO sind auf die Geschäftsanforderungen abgestimmt und so definiert:

  • RTO ist die maximale Zeit, die eine Datenbank ausfallen oder nicht verfügbar sein kann, bevor das Unternehmen inakzeptable Folgen wie Umsatz- oder Produktivitätsverluste erleidet.
  • RPO ist der maximale Datenverlust, den ein Unternehmen verkraften kann, bevor die Geschäftsanforderungen beeinträchtigt werden. Beispielsweise kann für Inventarsysteme, die einen vollständigen Audit-Trail erfordern, ein Datenverlust von null erforderlich sein.

AlloyDB Omni bietet die folgenden Referenzarchitekturen für die Verfügbarkeit, die unterschiedliche Verfügbarkeitsstufen bieten:

  1. Standardverfügbarkeit: Schützt Ihre Daten mithilfe von Sicherungen.
  2. Verbesserte Verfügbarkeit: Schützt Ihre Daten durch zonale Replikation in einer Region (HA).
  3. Premium-Verfügbarkeit: Schützt Ihre Daten durch zonale und regionale Replikation (Hochverfügbarkeit und Notfallwiederherstellung).

Verfügbarkeitsmechanismen

Die folgenden Mechanismen sorgen für die Verfügbarkeit:

  • Datenbanksicherungen
  • Datenbankreplikation

Datenbanksicherungen

Datenbanksicherungen sind ein grundlegender Aspekt des Datenschutzes und umfassen das Erstellen physischer Kopien von Datenbankdateien. Die verschiedenen Sicherungstypen (vollständig, inkrementell und differenziell) bieten unterschiedliche Verhältnisse zwischen Recovery Point Objective (RPO), Sicherungsgröße und -dauer sowie Wiederherstellungszeit.

Eine robuste Sicherungsstrategie muss sowohl Datenbank- als auch Write-Ahead-Log-Dateisicherungen (WAL) umfassen, um eine effiziente Wiederherstellung zu ermöglichen und Datenverluste bei Systemausfällen zu minimieren. Regelmäßige (normalerweise tägliche) Sicherungen von Datendateien sind entscheidend. Sie müssen auch WAL-Dateien sichern, in denen Datenbankänderungen aufgezeichnet werden und die für die Wiederherstellung zu einem bestimmten Zeitpunkt und die Aufrechterhaltung der Datenintegrität während der Wiederherstellung wichtig sind.

Datenbankreplikation

PostgreSQL bietet Replikatserver für mehr Zuverlässigkeit. Diese Replikate werden entweder als Warm-Standby-Replikate klassifiziert, die keine Anwendungsverbindungen akzeptieren, oder als Hot-Standby-Replikate, die im Lesemodus ausgeführt werden. Änderungen aus der primären Datenbank werden kontinuierlich auf das Replikat angewendet, damit die Daten des Replikats aktuell bleiben. Wenn die primäre Datenbank ausfällt, wird das Replikat zum primären Status hochgestuft und übernimmt die Aufgaben der primären Datenbank.

Datenbankreplikate können in derselben Zone oder demselben Rechenzentrum wie die primäre Instanz, in einer anderen Zone, in einer anderen Region oder in einer Kombination dieser Standorte platziert werden. Je weiter das Replikat von der primären Datenbank entfernt ist, desto höher ist die Latenz beim Senden von Änderungen, um die Replikate auf dem neuesten Stand zu halten. Bei Bereitstellungen an weit entfernten Standorten zur Minimierung von großflächigen Ausfällen, z. B. regionalen Fehlern, erfolgt die Datenreplikation in der Regel asynchron. So werden Leistungseinbußen vermieden, die bei solchen Konfigurationen auftreten können.

In Hochverfügbarkeitsbereitstellungen werden Replikate in der Regel in unmittelbarer Nähe der primären Datenbank bereitgestellt. Beispiel: Replikate, die in einer anderen Zone innerhalb desselben Rechenzentrums bereitgestellt werden, bieten niedrige RTOs und ein RPO von fast null. In Notfallwiederherstellungskonfigurationen werden Replikate dagegen in separaten Rechenzentren oder Regionen bereitgestellt, je nachdem, wie hoch der erforderliche Schutz vor Ausfällen ist. Dieser Ansatz führt zu einem höheren RPO (da die Replikation asynchron sein kann) und einem variablen RTO.

In der folgenden Tabelle sind die Mechanismen zusammengefasst, die für die Referenzarchitekturen für die AlloyDB Omni-Verfügbarkeit verwendet werden:

Feature Standard Erweiterter Support Premium
Sicherung Ja Ja Ja
Zonales Replikat Nein Ja Ja
Zonenübergreifendes Replikat Nein Ja Ja
Regionales Replikat Nein Nein Ja

Tabelle 1. Unterstützte Verfügbarkeitsmechanismen für AlloyDB Omni

Datenbankfehler und Wiederherstellungsszenarien

Datenbankfehler können auf den folgenden Ebenen auftreten:

  • Instanzausfall (Knoten oder Server): Die Datenbank selbst fällt aus.
  • Serverausfall: Der Server, auf dem die Datenbank gehostet wird, fällt aus.
  • Zonenausfall: Das gesamte Rechenzentrum, in dem sich der Server befindet, fällt aus.
  • Regionsausfall: Die gesamte Region mit mehreren Rechenzentren (Verfügbarkeitszonen) ist nicht verfügbar, z. B. aufgrund einer Überschwemmung oder eines Erdbebens.

Die Wahrscheinlichkeit und das Risiko eines Notfalls sinken, wenn es weniger Ereignisse gibt und die Kosten für die Verhinderung dieser Ereignisse steigen. Unternehmen müssen ihre Risikotoleranz bestimmen und entscheiden, ob sie potenzielle Störungen akzeptieren oder in resilientere Architekturen investieren, um Risiken zu minimieren.

In der folgenden Tabelle sind die Wiederherstellungsszenarien zusammengefasst, die von AlloyDB Omni-Referenzarchitekturen unterstützt werden:

Art der Katastrophe Standard Erweiterter Support Premium
VM-/Instanzausfall Ja Ja Ja
Knoten-/Serverfehler Ja Ja Ja
Zonenausfall Nein Ja Ja
Regionaler Ausfall Nein Nein Ja

Tabelle 2. Unterstützte Wiederherstellungsszenarien

Berücksichtigen Sie Ihre Geschäftsziele für Ihre AlloyDB Omni-Datenbank, z. B. die Notwendigkeit einer Verfügbarkeit von 99,99 % und eines Datenverlusts von null bei der Wiederherstellung für geschäftskritische Anwendungen. Das Ziel der Referenzarchitekturen für die Verfügbarkeit besteht darin, die RTO- und RPO-Anforderungen zu erfüllen.

AlloyDB Omni bietet Standard-, erweiterte und Premium-Verfügbarkeitsarchitekturen, um Datenbanken vor geplanten und ungeplanten Ausfällen zu schützen und so unterschiedlichen Geschäftsanforderungen gerecht zu werden. In Entwicklungsumgebungen kann beispielsweise ein grundlegender Schutz mit Sicherungen verwendet werden, während für geschäftskritische Anwendungen Hochverfügbarkeits- und Notfallwiederherstellungskonfigurationen eingesetzt werden können.

Nächste Schritte

Weitere Informationen zu den Referenzarchitekturen für die AlloyDB Omni-Verfügbarkeit: