Um die Geschäftskontinuität zu gewährleisten und Datenverluste zu minimieren, sind Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) entscheidende Datenschutzstrategien für AlloyDB Omni. HA konzentriert sich auf die Aufrechterhaltung der Datenbankverfügbarkeit und die Minimierung des Recovery Time Objective (RTO), während DR die Wiederherstellung nach katastrophalen Ereignissen und die Minimierung des Recovery Point Objective (RPO) umfasst.
RTO und RPO sind auf die geschäftlichen Anforderungen abgestimmt und werden wie folgt definiert:
- Das RTO ist die maximale Zeit, in der eine Datenbank nicht verfügbar sein kann, bevor das Unternehmen inakzeptable Folgen erleidet, z. B. Umsatz- oder Produktivitätsverluste.
- RPO ist der maximale Datenverlust, den ein Unternehmen erleiden kann, bevor dies Auswirkungen auf die geschäftlichen Anforderungen hat. Bei Inventarsystemen, die einen vollständigen Audit-Trail erfordern, kann beispielsweise ein Datenverlust von null erforderlich sein.
AlloyDB Omni bietet die folgenden Verfügbarkeitsreferenzarchitekturen, die ein zunehmendes Maß an Verfügbarkeit bieten:
- Standardverfügbarkeit: Schützt Ihre Daten mit Sicherungen.
- Erweiterte Verfügbarkeit: Schützt Ihre Daten mit zonaler Replikation in einer Region (HA).
- Premium-Verfügbarkeit: Schützt Ihre Daten mit zonaler und regionaler Replikation (HA und DR).
Verfügbarkeitsmechanismen
Die folgenden Mechanismen sorgen für Verfügbarkeit:
- Datenbanksicherungen
- Datenbankreplikation
Datenbanksicherungen
Datenbanksicherungen sind ein grundlegender Aspekt des Datenschutzes und umfassen das Erstellen physischer Kopien von Datenbankdatendateien. Verschiedene Sicherungstypen – vollständig, inkrementell und differenziell – bieten unterschiedliche Kompromisse zwischen RPO, Sicherungsgröße und -dauer sowie Wiederherstellungszeit.
Um eine effiziente Wiederherstellung zu gewährleisten und Datenverluste bei 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 entscheidend. Sie müssen auch WAL-Dateien sichern, in denen Datenbankänderungen aufgezeichnet werden und die für die Point-in-Time-Wiederherstellung und die Aufrechterhaltung der Datenintegrität während der Wiederherstellung unerlässlich sind.
Datenbankreplikation
PostgreSQL bietet Replikaserver für mehr Zuverlässigkeit. Diese Replikate werden entweder als Warm Standbys klassifiziert, die keine Anwendungsverbindungen akzeptieren, oder als Hot Standbys, die im Lesemodus 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 zum primären Replikat hochgestuft und übernimmt die Aufgaben der primären Datenbank.
Datenbankreplikate können sich 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 befinden. 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 Ausfällen im großen Maßstab, z. B. bei regionalen Ausfällen, erfolgt die Datenreplikation in der Regel asynchron. Dieser Ansatz vermeidet Leistungseinbußen, die in solchen Setups 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 zur Notfallwiederherstellung werden Replikate hingegen 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 ist) und zu unterschiedlichen RTOs.
In der folgenden Tabelle sind die Mechanismen zusammengefasst, die für die AlloyDB Omni-Verfügbarkeitsreferenzarchitekturen verwendet werden:
| Feature | Standard | Erweiterter Support | Premium |
|---|---|---|---|
| Sicherung | ✔ | ✔ | ✔ |
| Zonales Replikat | ❌ | ✔ | ✔ |
| Zonenübergreifendes Replikat | ❌ | ✔ | ✔ |
| Regionales Replikat | ❌ | ❌ | ✔ |
Tabelle 1 : Unterstützte AlloyDB Omni-Verfügbarkeitsmechanismen
Datenbankausfälle und Wiederherstellungsszenarien
Datenbankausfälle 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 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 bestimmen und entscheiden, ob sie potenzielle Störungen akzeptieren oder in robustere Architekturen investieren, um Risiken zu minimieren.
In der folgenden Tabelle sind die Wiederherstellungsszenarien zusammengefasst, die von den AlloyDB Omni-Referenzarchitekturen unterstützt werden:
| Art der Katastrophe | Standard | Erweiterter Support | Premium |
|---|---|---|---|
| VM-/Instanzausfall | ✔ | ✔ | ✔ |
| Knoten-/Serverausfall | ✔ | ✔ | ✔ |
| Zonenausfall | ❌ | ✔ | ✔ |
| Regionsausfall | ❌ | ❌ | ✔ |
Tabelle 2 : Unterstützte Wiederherstellungsszenarien
Berücksichtigen Sie Ihre Geschäftsziele für Ihre AlloyDB Omni-Datenbank, z. B. den kritischen Bedarf an mehreren 9en (99,99%) Verfügbarkeit und keinem Datenverlust bei der Wiederherstellung für geschäftskritische Anwendungen. Ziel der Verfügbarkeitsreferenzarchitekturen 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äftlichen Anforderungen gerecht zu werden. In Entwicklungsumgebungen kann beispielsweise ein grundlegender Schutz mit Sicherungen verwendet werden, während für geschäftskritische Anwendungen Setups für Hochverfügbarkeit und Notfallwiederherstellung eingesetzt werden können.
Nächste Schritte
Weitere Informationen zu den AlloyDB Omni-Verfügbarkeitsreferenzarchitekturen:
- Daten mit Sicherungen schützen (Standardverfügbarkeit).
- Daten mit zonaler Replikation in einer Region schützen (erweiterte Verfügbarkeit).
- Daten mit zonaler und regionaler Replikation schützen (Premium-Verfügbarkeit).