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

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 wenig oder gar keinem Datenverlust wiederhergestellt werden kann.

Um Geschäftskontinuität zu gewährleisten und Datenverlust zu minimieren, sind Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) entscheidende Datenschutzstrategien für AlloyDB Omni. Bei HA geht es darum, die Datenbankverfügbarkeit aufrechtzuerhalten und das Recovery Time Objective (RTO) zu minimieren. Bei DR geht es um die Wiederherstellung nach katastrophalen Ereignissen und die Minimierung des Recovery Point Objective (RPO).

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

  • RTO ist die maximale Zeit, in der eine Datenbank ausfallen oder nicht verfügbar sein kann, bevor das Unternehmen inakzeptable Folgen wie Umsatz- oder Produktivitätsverluste erleidet.
  • Das RPO ist die maximale Menge an Datenverlust, die ein Unternehmen erleiden kann, bevor es sich auf die Geschäftsanforderungen auswirkt. Bei Inventarsystemen, die einen vollständigen Prüfpfad erfordern, kann beispielsweise ein Datenverlust von null erforderlich sein.

AlloyDB Omni bietet die folgenden Referenzarchitekturen für die Verfügbarkeit, die ein jeweils höheres Maß an Verfügbarkeit bieten:

  1. Standardverfügbarkeit: Ihre Daten werden durch Back-ups geschützt.
  2. Höhere Verfügbarkeit: Ihre Daten werden durch zonale Replikation in einer Region geschützt (Hochverfügbarkeit).
  3. Premium-Verfügbarkeit: Schützt Ihre Daten durch zonale und regionale Replikation (Hochverfügbarkeit und Notfallwiederherstellung).

Verfügbarkeitsmechanismen

Die folgenden Hauptmechanismen sorgen für Verfügbarkeit:

  • Datenbanksicherungen
  • Datenbankreplikation

Datenbanksicherungen

Datenbanksicherungen sind ein grundlegender Aspekt des Datenschutzes. Dabei werden physische Kopien von Datenbankdatendateien erstellt. Verschiedene Sicherungstypen – vollständig, inkrementell und differenziell – bieten unterschiedliche Kompromisse zwischen RPO (Recovery Point Objective), Sicherungsgröße und -dauer sowie Wiederherstellungszeit.

Um eine effiziente Wiederherstellung zu gewährleisten und Datenverluste im Falle von Systemausfällen zu minimieren, muss eine robuste Sicherungsstrategie sowohl Datenbank- als auch Write-Ahead-Log-Dateisicherungen (WAL) umfassen. Regelmäßige (in der Regel tägliche) Sicherungen von Datendateien sind unerlässlich. Sie müssen auch WAL-Dateien sichern, in denen Datenbankänderungen aufgezeichnet werden. Sie sind für die Wiederherstellung zu einem bestimmten Zeitpunkt und die Aufrechterhaltung der Datenintegrität während der Wiederherstellung von entscheidender Bedeutung.

Datenbankreplikation

PostgreSQL bietet Replikaserver für eine höhere Zuverlässigkeit. Diese Replikate werden entweder als Warm-Standby-Instanzen klassifiziert, die keine Anwendungsverbindungen akzeptieren, oder als Hot-Standby-Instanzen, die im schreibgeschützten Modus ausgeführt werden. Änderungen aus der primären Datenbank werden kontinuierlich auf das Replikat angewendet, um die Daten des Replikats auf dem neuesten Stand zu halten. Wenn die primäre Datenbank ausfällt, wird das Replikat zur primären Datenbank hochgestuft und übernimmt deren Aufgaben.

Datenbankreplikate können in derselben Zone oder demselben Rechenzentrum wie die primäre Instanz, in einer anderen Zone, in einer anderen Region oder an einer Kombination dieser Standorte platziert werden. Je weiter das Replikat von der primären Datenbank entfernt ist, desto größer 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 Fehlern wie regionalen Ausfällen erfolgt die Datenreplikation in der Regel asynchron. So lassen sich Leistungseinbußen vermeiden, die in solchen Konfigurationen auftreten können.

Bei Bereitstellungen mit Hochverfügbarkeit werden Replikate in der Regel in unmittelbarer Nähe der primären Datenbank bereitgestellt. Replikate, die in einer anderen Zone innerhalb desselben Rechenzentrums bereitgestellt werden, bieten beispielsweise niedrige RTOs und ein RPO von nahezu null. Bei Konfigurationen für die Notfallwiederherstellung werden Replikate dagegen in separaten Rechenzentren oder Regionen bereitgestellt, je nach dem erforderlichen Schutz vor Ausfällen. Dieser Ansatz führt zu einem höheren RPO (da die Replikation möglicherweise asynchron erfolgt) und zu einem variablen RTO.

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

Feature Standard Optimiert Premium
Sicherung ✔ ✔ ✔
Zonales Replikat ❌ ✔ ✔
Zonenübergreifendes Replikat ❌ ✔ ✔
Regionales Replikat ❌ ❌ ✔

Tabelle 1. Unterstützte AlloyDB Omni-Verfügbarkeitsmechanismen

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.
  • Ausfall einer Region: Die gesamte Region mit mehreren Rechenzentren (Verfügbarkeitszonen) ist nicht verfügbar, z. B. aufgrund einer Überschwemmung oder eines Erdbebens mit hoher Magnitude.

Die Wahrscheinlichkeit und das Risiko einer Katastrophe sinken, wenn es weniger Ereignisse gibt und die Kosten für die Verhinderung dieser Ereignisse steigen. Unternehmen müssen ihre Risikobereitschaft festlegen und entscheiden, ob sie potenzielle Störungen in Kauf nehmen oder in robustere Architekturen investieren möchten, um Risiken zu minimieren.

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

Art des Notfalls Standard Optimiert Premium
VM-/Instanzfehler ✔ ✔ ✔
Knoten-/Serverfehler ✔ ✔ ✔
Zonenausfall ❌ ✔ ✔
Regionaler Ausfall ❌ ❌ ✔

Tabelle 2. Unterstützte Wiederherstellungsszenarien

Berücksichtigen Sie Ihre Geschäftsziele für Ihre AlloyDB Omni-Datenbank, z. B. den kritischen Bedarf an einer Verfügbarkeit von 99,99 % und keinen Datenverlust bei der Wiederherstellung für geschäftskritische Anwendungen. Ziel der Referenzarchitekturen für die Verfügbarkeit ist es, 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 unterschiedlichen Geschäftsanforderungen gerecht zu werden. In Entwicklungsumgebungen wird beispielsweise möglicherweise ein grundlegender Schutz mit Backups verwendet, während für geschäftskritische Anwendungen Hochverfügbarkeits- und Notfallwiederherstellungseinrichtungen eingesetzt werden können.

Nächste Schritte

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