Optionen für die Notfallwiederherstellung von Oracle-Datenbankarbeitslasten

In diesem Leitfaden werden die Optionen für die Notfallwiederherstellung beschrieben, die für Nutzer verfügbar sind, die geschäftskritische Oracle-Datenbankarbeitslasten in einer Bare-Metal-Lösungsumgebung ausführen.

In diesem Leitfaden wird davon ausgegangen, dass Sie Oracle Enterprise Edition verwenden. Einige der in diesem Leitfaden beschriebenen Funktionen sind nicht in der Enterprise Edition-Lizenz enthalten und müssen separat lizenziert werden. Zu diesen Funktionen gehören unter anderem:

  • Oracle Real Application Clusters
  • Oracle Active Data Guard
  • Oracle Advanced Compression
  • Oracle GoldenGate

Lesen Sie Ihre Oracle-Lizenzvereinbarungen, um zu ermitteln, welche Funktionen Sie bei der Planung der Notfallwiederherstellung und Hochverfügbarkeit verwenden dürfen.

RTO und RPO der Anwendung

Die Notfallwiederherstellung für Oracle-Datenbanktechnologien muss anhand des Recovery Time Objective (RTO) und des Recovery Point Objective (RPO) einer Anwendung bestimmt werden. Im Allgemeinen beschreibt RTO die zulässige Ausfallzeit für ein System und RPO den zulässigen Datenverlust. Die Kosten und die Komplexität eines Systems steigen, wenn jeder dieser Werte sinkt. Weitere Informationen zu RTO und RPO finden Sie unter Grundlagen der Planung der Notfallwiederherstellung.

Bei Architekturen mit dem Label „RPO = 0“ oder „Null Datenverlust“ müssen die Daten an mehreren Stellen geschrieben werden, bevor sie als „in der Datenbank verbindlich“ betrachtet werden. Die Latenz wird zu einem Problem, wenn sich der RPO dem Nullpunkt nähert.

Wenn dies in der Designphase nicht richtig berücksichtigt wird, kann die Implementierung einer Architektur ohne Datenverluste negative Auswirkungen auf die Gesamtleistung der Anwendung haben.

Hochverfügbarkeit und Notfallwiederherstellung

Hochverfügbarkeit und Notfallwiederherstellung sind sich ergänzende Konzepte beim Entwerfen zuverlässiger Datenbankarchitekturen. Im Kontext dieses Leitfadens bezieht sich „Hochverfügbarkeit“ auf die Fähigkeit eines Systems, sich automatisch von einzelnen oder kaskadierenden Systemausfällen zu erholen. Die Notfallwiederherstellung ist dagegen Teil eines allgemeinen Notfallwiederherstellungsplans und gilt für größere Ausfälle, die ganze Systemgruppen lahmlegen können. Die Notfallwiederherstellung umfasst aufgrund der Anzahl der integrierten Komponenten, die im Notfall wiederhergestellt werden müssen, einen größeren Umfang.

Die Hochverfügbarkeit muss bei der Entwicklung eines zuverlässigen Systems als „erste Verteidigungslinie“ betrachtet werden. Eine hochverfügbare Datenbankarchitektur muss einzelne Ausfälle verkraften und weiterlaufen können, ohne dass es zu einer Ausfallzeit für die Anwendung kommt. Die Hochverfügbarkeitskomponenten eines Systems umfassen unter anderem Folgendes:

  • Redundante Stromversorgung für Server-, Netzwerk- oder Speicherhardware
  • Mehrere Netzwerkschnittstellen, Switches und Kabel
  • Redundante Speicher-Fabrics, Controller und Laufwerkgeräte
  • Ausfallsichere Partner Interconnects zwischen Google Cloud und der regionalen Erweiterung der Bare-Metal-Lösung
  • Oracle RAC, um zu verhindern, dass Serverfehler eine Datenbank deaktivieren

Ein Notfallwiederherstellungsdesign muss Prozesse zur Wiederherstellung nach mehreren kaskadierenden Fehlern enthalten, die Komponenten unzugänglich machen. Bei der Planung der Notfallwiederherstellung müssen Folgendes berücksichtigt werden:

  • Regionale Ausfälle
  • Naturkatastrophen
  • Vorfälle, die zu einem vollständigen Ausfall einer oder mehrerer Komponenten einer Anwendung führen

Oracle-Tools für Notfallwiederherstellung und Hochverfügbarkeit

Im Folgenden finden Sie einige Oracle-Tools für Notfallwiederherstellung und Hochverfügbarkeit:

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) werden verwendet, um Datenbankarbeitslasten horizontal zu skalieren, damit sie von mehreren Datenbankservern verarbeitet werden können. Datenbanken, die RAC verwenden, ermöglichen eine Aktiv/Aktiv-Konfiguration zwischen Servern innerhalb einer Regionserweiterung.

RAC wird in der Regel verwendet, um eine hohe Verfügbarkeit für Systeme zu bieten, die vor einem einzelnen Serverausfall geschützt werden müssen. Aufgrund des Ansatzes „Alles gemeinsam nutzen“ (freigegebener Speicher und freigegebene Netzwerke) für das Clustern muss ein RAC-Cluster, der in einer Bare-Metal-Lösungsumgebung ausgeführt wird, in einem einzelnen Bare-Metal-Lösung-Pod vorhanden sein. Dies macht RAC zu einer Lösung für Hochverfügbarkeitsprobleme, erfüllt aber nicht die Anforderungen an die Notfallwiederherstellung.

Informationen zum Einrichten von RAC für die Bare-Metal-Lösung finden Sie unter Oracle RAC auf Bare-Metal-Lösung installieren.

Oracle Recovery Manager

Oracle Recovery Manager (RMAN) ist das primäre Tool für die Sicherung und Wiederherstellung von Oracle-Datenbanken, da es das proprietäre Datendateiformat von Oracle lesen kann. Sie können damit Datenbankklone erstellen, eine Wiederherstellung zu einem bestimmten Zeitpunkt ausführen oder sogar eine einzelne Tabelle in einer Oracle-Datenbank wiederherstellen.

RMAN ist das einzige Tool, mit dem Sicherungen erstellt werden können, während die Datenbank geöffnet ist. Außerdem wird er verwendet, um den Katalog der Sicherungsdateien zu verwalten, die für die Wiederherstellung verfügbar sind.

Oracle Data Guard

Oracle Data Guard führt die Datenbankreplikation auf Remote-RAC-Cluster oder andere Datenbankinstallationen aus. Data Guard unterstützt Standby-Datenbanken entweder in einer physischen oder logischen Konfiguration.

Physische Standby-Datenbanken sind Block-für-Block-Kopien, die es ermöglichen, eine Kopie der Datenbank zum Schreiben zu öffnen. Alle anderen werden entweder bereitgestellt (aber nicht geöffnet), um Änderungen anzuwenden, oder schreibgeschützt geöffnet, um Berichtsanwendungen zu unterstützen.

Informationen zum Einrichten von Data Guard in einer Bare-Metal-Lösung finden Sie unter Oracle Data Guard auf Bare-Metal-Lösung bereitstellen.

FLASHBACK DATABASE

Mit der Funktion FLASHBACK DATABASE der Oracle Enterprise Edition können Administratoren eine Datenbank schnell auf einen bestimmten Zeitpunkt zurückspulen, ohne zeitaufwendige Datenbankwiederherstellungen ausführen zu müssen.

Im Zusammenhang mit der Notfallwiederherstellung wird FLASHBACK DATABASE häufig in Verbindung mit Data Guard während Failover-Vorgängen verwendet, um die Datenbankwiederherstellung zu beschleunigen. Die fehlerhafte Datenbank wird auf einen bestimmten Zeitpunkt zurückgeflasht, der mit den Logs auf der neuen primären Datenbank übereinstimmt. Die Datenbank wird dann noch einmal ausgeführt, damit sie vollständig neu synchronisiert werden kann.

Oracle GoldenGate

Oracle GoldenGate ist ein logisches Replikationstool, das häufig zum Aktivieren von Aktiv/Aktiv-Multi-Site-Bereitstellungen oder zum Verschieben von Daten zwischen Hardwareplattformen verwendet wird. Bei der Verwendung von GoldenGate erfasst ein extract-Prozess in der Quelldatenbank Änderungen in den Online-Transaktionsprotokollen und schreibt diese in Änderungs-Trail-Dateien, die zur Zieldatenbank übertragen werden. Ein replicat-Prozess in der Zieldatenbank konvertiert Transaktionen aus den Tail-Dateien in SQL und führt die SQL-Anweisungen in der Zieldatenbank aus.

Diese Architektur macht GoldenGate zu einem leistungsstarken Tool zum Verschieben von Daten zwischen Datenbankplattformen oder zum Transformieren von Daten bei der Replikation. Im Gegensatz zu Data Guard muss für GoldenGate separate Software auf den Quell- und Zielsystemen installiert und verwaltet werden. GoldenGate kann nicht für die synchrone Replikation verwendet werden, da Transaktionen in SQL übersetzt und auf die Zieldatenbank angewendet werden. GoldenGate kann zwar eine minimale Verzögerung bei der Replikation bieten, aber allein GoldenGate kann kein RPO von null garantieren.

Bereitstellungsmodelle für die Notfallwiederherstellung (nur Datenbank)

Oracle hat das MAA-Framework (Maximum Availability Architecture) entwickelt, um Ihnen empfohlene Notfallwiederherstellungsmodelle für die Bereitstellung Ihrer Anwendungen und Datenbanken zur Verfügung zu stellen.

Für jedes der folgenden Modelle gelten bestimmte RTO- und RPO-Ziele:

Die Modelle werden bestimmten Bereitstellungsmustern zugeordnet, die bei geplanten und ungeplanten Ausfällen die RPO und RTO erfüllen. Jede Datenbankarbeitslast muss auf ihre Verfügbarkeitsanforderungen hin überprüft und mit einem entsprechenden Modell entworfen werden. Für Entwicklungsdatenbanken wird häufig ein Modell mit einem niedrigeren Schutzniveau verwendet als für Produktions- und QA-Datenbanken.

Das Bronze-Modell ist für Datenbanken gedacht, für die keine RTO in Minuten erforderlich ist. Die Modelle der Stufe „Silber“ und höher umfassen Standby-Datenbanken, die an einem Remote-Standort ausgeführt werden. Jedes Modell enthält die Funktionen der Modelle der unteren Ebene. Das Bronze-Modell verwendet beispielsweise Sicherungs- und Wiederherstellungskonzepte, die auch dann eingehalten werden müssen, wenn eine Standby-Datenbank bereitgestellt wird.

Kupfermodell

Das Kupfermodell bietet eine minimale Bereitstellung, um Datenbanken auf lokalen Speichermedien zu sichern und in einen Speicher zu kopieren, der sich außerhalb der Regionserweiterung befindet. Diese Bereitstellung erfordert einen zweistufigen Ansatz, kann aber mit einem Script so konfiguriert werden, dass die Übertragung von Sicherungen mit dem Google Cloud SDK automatisiert wird.

Bei dieser Bereitstellung erhöht sich auch die RTO aufgrund der erforderlichen zweistufigen Wiederherstellung. RMAN kann nicht direkt auf die Sicherungen zugreifen. Sie müssen daher an einen für RMAN zugänglichen Speicherort verschoben werden, bevor die Wiederherstellung beginnen kann.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Beschädigungen Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung, die aus dem RE übertragen wurde Stunden, abhängig von der Datenbankgröße und der Partner Interconnect zugewiesenen Bandbreite
Katastrophen: Ausfälle bei der Regionenerweiterung Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung, die aus dem RE übertragen wurde Tage / Wochen, je nachdem, wie lange es dauert, die Region wieder online zu stellen
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
Großes Datenbank-Upgrade 0 1–2 Stunden

Bronzemodell

Das Bronze-Modell bietet zwei Bereitstellungsoptionen. Beide verwenden den cloudnativen Speicher von Google Cloud zum Aufbewahren von Datenbanksicherungen.

Bronze-Bereitstellung 1: Sicherung im regionalen Speicher

Bei dieser Bereitstellung werden Sicherungen direkt auf externe Medien geschrieben. In den meisten Fällen ist Cloud Storage mit Cloud Storage FUSE das bevorzugte Sicherungsziel. Dabei wird ein Cloud Storage-Bucket als Dateisystem dargestellt.

Empfehlungen zur Verwendung von Cloud Storage FUSE finden Sie unter „Oracle-Sicherungen mit NFS und Cloud Storage“. Auch Google Cloud Filestore kann verwendet werden, um NFS-Freigaben für die Bare-Metal-Lösungsinstanzen bereitzustellen.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Oracle Bronze-Modellbereitstellung mit Sicherungen, die in einem regionalen Speicher aufbewahrt werden.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Beschädigungen Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung Stunden, abhängig von der Datenbankgröße und der Partner Interconnect zugewiesenen Bandbreite
Katastrophen: Ausfälle bei der Regionenerweiterung Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung Tage / Wochen, je nachdem, wie lange es dauert, die Region wieder online zu stellen
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
Großes Datenbank-Upgrade 0 1–2 Stunden

Bronze-Bereitstellung 2: Sicherung mit dem Sicherungs- und Notfallwiederherstellungsdienst

In dieser Bereitstellung wird der Sicherungs- und Notfallwiederherstellungsdienst verwendet, um Sicherungen in Google Cloud zu speichern. Sicherung und Notfallwiederherstellung bieten einen ständigen inkrementellen Ansatz für Sicherungen, die auf Hochleistungsmedien gespeichert werden, die für eine langfristige Aufbewahrung durch Cloud Storage unterstützt werden.

Sicherung und Notfallwiederherstellung bieten außerdem eine schnellere Wiederherstellungszeit als das Speichern von Sicherungen in Filestore oder Cloud Storage, da damit sofort Images von Datenbankdateien für die Oracle-Instanz verfügbar gemacht werden können. Mit der Funktion „Bereitstellen und migrieren“ können Sie eine Datenbank schnell online stellen und gleichzeitig auf die Produktionsspeichermedien zurückkopieren. Dadurch wird die Wiederherstellungszeit drastisch reduziert.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Bronze-Bereitstellung von Google Cloud Backup und DR

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung Minuten bis Stunden, je nach Leistungsanforderungen, Datenbankgröße und Bandbreite, die dem Partner Interconnect zugewiesen ist
Katastrophen: Ausfälle bei der Regionenerweiterung Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung Tage / Wochen, je nachdem, wie lange es dauert, die Regionalerweiterung wieder online zu stellen oder der Kunde zu einer anderen Regionalerweiterung zu wechseln.
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
Großes Datenbank-Upgrade 0 1–2 Stunden

Silber

Beim Silbermodell wird die Datenbankreplikation mit Oracle Data Guard eingeführt. Data Guard bietet eine Echtzeit-Datenbankreplikation mit einer oder mehreren Datenbanken, die als Standby-Datenbank dienen. Da Data Guard Datenbankänderungen bei Bedarf überträgt und anwendet, kann der RPO nahezu null sein. Das Silber-Modell basiert auf der asynchronen Replikation. Bei der synchronen Replikation kommt es zu keinen Datenverlusten, aber die Zeit, die zum Senden von Daten zwischen Regionen benötigt wird, überschreitet in der Regel die akzeptablen Grenzen der Anwendungsantwortzeit.

Die Fast-Start-Failover-Funktion von Data Guard kann automatische Failover-Vorgänge ausführen, wenn eine primäre Datenbank für einen vom Nutzer definierten Zeitraum nicht verfügbar ist. Die Konfiguration wird von einem Data Guard-Beobachterprozess überwacht, der ausgeführt werden kann.

Das Silbermodell hat den Vorteil, dass die Datenbank im Falle eines vollständigen regionalen Ausfalls verfügbar ist. Failover- und Umstellungsvorgänge können sich jedoch auf die Anwendungsleistung auswirken, da die Netzwerklatenz zwischen den Anwendungsservern und der Datenbank zunimmt. Es wird selten empfohlen, Anwendungen und unterstützende Datenbanken in verschiedenen Regionen auszuführen. Die RTO für die Datenbank kann unter einer Minute liegen, bei einem Anwendungs-Failover kann es jedoch Minuten bis Stunden dauern, bis die Dienste wieder vollständig funktionsfähig sind. In den meisten Fällen sind für die Ausführung von regionenübergreifenden Notfallwiederherstellungs-Failover-Plänen aufgrund der Anzahl der verschobenen Komponenten in der Regel manuelle Prozesse erforderlich.

Beim Silver-Modell können Sie bei vierteljährlichen Patch-Aktivitäten weiterhin Ausfallzeiten oder Wartungsfenster einplanen. Die Einführung von Oracle RAC kann die Ausfallzeiten bei Patches oder Serverausfällen reduzieren.

Das folgende Diagramm zeigt eine Beispielkonfiguration.

Standardzuordnung mit VRF

Die Beispielkonfiguration im Diagramm zeigt RAC-Datenbanken, die in den Regionen us-west2 und us-east4 ausgeführt werden. Die Replikation wird mithilfe der asynchronen Data Guard-Technologie konfiguriert. Der gesamte Traffic zwischen der Bare-Metal-Lösung und Google Cloud wird über ein Partner Interconnect geleitet. Regionsübergreifender Traffic wird über das Google-Netzwerk-Backbone übertragen. Anwendungsserver werden in jeder Region konfiguriert, aber in der Region für die Notfallwiederherstellung in der Regel heruntergefahren, bis ein Failover-Ereignis deklariert wird.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen < 60 Sekunden Minuten bis Stunden, je nach Anwendungs-Failover.
Katastrophen: Ausfälle bei der Regionenerweiterung < 60 Sekunden Minuten bis Stunden, je nach Anwendungs-Failover.
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist.

Sekunden bei Verwendung von RAC
Großes Datenbank-Upgrade 0 1–2 Stunden

Minuten, wenn Sie das Upgrade mit DBMS_ROLLING ausführen.

Goldmodell

Wenn Sie Bedenken hinsichtlich des Datenverlusts beim Silber-Modell haben, können Sie das Gold-Modell verwenden. Dabei wird eine Remote-Synchronisationsinstanz verwendet, um eine synchrone Replikation auf einer Instanz bereitzustellen, die in der Google Cloud Compute Engine ausgeführt wird.

Eine Remote-Synchronisierungs-Instanz enthält eine Datenbankkontrolldatei und eine Reihe von Standby-Wiederherstellungsprotokollen, die geografisch in der Nähe der primären Datenbank ausgeführt werden. Diese Instanz ist so konfiguriert, dass sie das Wiederherstellen synchron mit geringer Latenz empfängt, sodass alle Änderungen außerhalb der Regionserweiterung der primären Datenbank aufgezeichnet werden können. Die Far Sync-Instanz leitet die Wiederherstellung dann an die Standby-Datenbank in der Remote-Region weiter, um sie asynchron anzuwenden.

Eine Remote-Synchronisierungs-Instanz ist keine vollständige Kopie der Datenbank und kann daher keinen Anwendungsverkehr bedienen. Die Remote-Synchronisationsinstanz dient als fehlertoleranter Speicherort, an dem Datenbankänderungen synchron geschrieben werden können. So lassen sich Datenverluste vermeiden. Bei der synchronen Replikation in die Remote-Synchronisationsinstanz werden Transaktionen erst in der primären Datenbank verbindlich, wenn die Änderungen in der Remote-Synchronisationsinstanz empfangen und verbindlich gemacht wurden.

Die Compute Engine-Instanzen werden in der Regel als Kandidaten für das Hosten einer Remote-Synchronisierungs-Instanz ausgewählt. Wenn Sie die Instanz für die Remotesynchronisierung in einer Compute Engine-Zone in der Nähe der primären Datenbank platzieren, wird eine minimale Latenz (in der Regel unter 1,5 ms) hinzugefügt und Sie sind vor Ausfällen innerhalb der Regionserweiterung geschützt.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Oracle Gold-Synchronisierung.

Die Beispielkonfiguration im Diagramm zeigt eine primäre RAC-Datenbank, die in us-west2 ausgeführt wird, mit Anwendungen, die in der Compute Engine ausgeführt werden. Auf einer Compute Engine-Instanz in us-west2 wird eine Remote-Synchronisierungs-Instanz ausgeführt, die synchrone Wiederholungen empfängt. Die Remote-Synchronisierungs-Instanz ist so konfiguriert, dass Redo-Daten asynchron an eine RAC-Datenbank gesendet werden, die in der Region us-east4 ausgeführt wird. Anwendungsinstanzen werden in der Region us-east4 in der Compute Engine konfiguriert, um Anwendungstraffic bei einem Notfall zu verarbeiten.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen 0 Minuten bis Stunden, je nach regionalem Failover der Anwendung.
Katastrophen: Ausfälle bei der Regionenerweiterung 0 Minuten bis Stunden, je nach regionalem Failover der Anwendung.
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist.

Sekunden bei Verwendung von RAC
Großes Datenbank-Upgrade 0 1–2 Stunden

Minuten, wenn Sie das Upgrade mit DBMS_ROLLING ausführen.

Platinmodell

Das Platinum-Modell bietet zwei Bereitstellungsoptionen. Jede Bereitstellungsoption bietet Schutz mit einer anderen Technologie und hat unterschiedliche RTO- und RPO-Eigenschaften.

Platinum-Bereitstellung 1: Data Guard mit Fast-Start-Failover

Die Bereitstellung „Platinum 1“ basiert auf der Bereitstellung des Gold-Modells. Dazu wird eine zweite Data Guard-Standby-Datenbank in der lokalen Region hinzugefügt, die auf einer Compute Engine-Instanz ausgeführt wird. Bei dieser Konfiguration wird eine synchrone Replikation zwischen der primären Datenbank und der Standby-Datenbank in der Compute Engine verwendet. So wird innerhalb der primären Region ein Datenverlust ausgeschlossen.

Wenn Sie eine Standby-Datenbank in der Region erstellen, können Datenbank-Failover und ‑Wechselvorgänge durchgeführt werden, ohne dass Anwendungen beeinträchtigt werden. Bei Änderungen der Datenbankrolle stellen Anwendungen, die gemäß den Clientüberlegungen von Oracle konfiguriert sind, automatisch eine Verbindung zur neuen primären Datenbank her, ohne dass manuelle Eingriffe erforderlich sind. Bei ordnungsgemäß konfigurierten Anwendungen beträgt die Ausfallzeit bei einem Failover weniger als zwei Minuten.

In der Standby-Datenbank in der Compute Engine wird kein RAC ausgeführt. Sie muss jedoch so dimensioniert sein, dass sie den normalen Anwendungsverkehr unterstützt, wenn sie als primäre Datenbank ausgeführt wird. Diese Instanz kann entweder mit einer kleineren Form als Standby ausgeführt und bei Failover-Ereignissen skaliert werden oder immer mit voller Kapazität laufen. Wenn Sie die Größe der Instanz während eines Failover-Ereignisses ändern, wirkt sich das negativ auf die RTO aus, da die Instanz während des Größenänderungsvorgangs neu gestartet werden muss.

Das Fast-Start-Failover wird auf einer Compute Engine-Instanz konfiguriert, auf der der Data Guard-Broker mit einem Beobachter ausgeführt wird. Der Beobachter führt einen einfachen Oracle-Client mit Verbindungen zu allen primären und Standby-Datenbanken aus. Wenn der Beobachter einen Fehler in der primären Datenbank erkennt, initiiert er ein Failover auf eine der Standby-Datenbanken. Die in der Compute Engine ausgeführte Standby-Datenbank muss als bevorzugtes Failover-Ziel konfiguriert werden, wenn die Gold-Stufe verwendet wird.

Oracle empfiehlt, den Beobachter in einer Region zu platzieren, die von der primären und der Standby-Datenbank getrennt ist. Dies bietet den besten Schutz vor regionalen Ausfällen und Netzwerkpartitionierungsereignissen. Wenn eine dritte Region nicht möglich ist, muss der Beobachter in der primären Region installiert werden und in einer anderen Zone als der Near-Site-Standby-Instanz ausgeführt werden.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Oracle Platinum-Bereitstellung von Data Guard mit schnellem Failover.

Die im Diagramm dargestellte Beispielbereitstellung besteht aus folgenden Elementen:

  • Eine primäre Datenbank, auf der RAC auf einem Bare-Metal-Lösungsserver in der Region us-west2 ausgeführt wird.
  • Eine Near-Site-Standby-Datenbank, die auf einer Compute Engine-Instanz in der Region us-west2 ausgeführt wird.
  • Eine Remote-Standby-Datenbank, die auf einem Bare-Metal-Lösungsserver in der Region us-east4 ausgeführt wird.
  • Der Data Guard-Beobachter, der auf einer Compute Engine-Instanz in der Region us-central1 ausgeführt wird.

Die synchrone Replikation ist für die Standby-Datenbank in der Region konfiguriert, die auf der Compute Engine-Instanz ausgeführt wird, und die asynchrone Replikation ist für die Remote-Region konfiguriert. In jedem Fall wird das Wiederherstellen von der primären Datenbank an die Standby-Datenbank gesendet. Es wird nicht von einer Standby-Datenbank an die andere weitergeleitet. Der Beobachter ist in einer dritten Region konfiguriert und stellt die Verbindung zu allen Datenbanken in der Konfiguration aufrecht. Anwendungsinstanzen werden in der primären Region konfiguriert und stellen eine Verbindung zur primären Datenbank auf dem Bare-Metal-Lösungsserver her (oder zur Datenbank auf der Compute Engine-Instanz bei Failover- und Umstellungsvorgängen). Anwendungsinstanzen werden in der Region us-east4 in der Compute Engine konfiguriert, um Anwendungsverkehr im Notfall zu verarbeiten.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen 0 < 60 Sekunden
Katastrophen: Ausfälle bei der Regionenerweiterung 0 < 60 Sekunden
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist.

Sekunden bei Verwendung von RAC
Großes Datenbank-Upgrade 0 1–2 Stunden

Minuten, wenn Sie das Upgrade mit DBMS_ROLLING ausführen.

Platin-Bereitstellung 2: GoldenGate für die Replikation

Bei der Platin-Bereitstellung 2 wird Oracle GoldenGate für die Replikation verwendet. Da GoldenGate nicht auf Blockebene repliziert. So kann jede Datenbank Anwendungssitzungen unabhängig lesen und schreiben. Es repliziert die Änderungen bidirektional, was eine Aktiv/Aktiv-Datenbankkonfiguration ermöglicht.

Anwendungen müssen gründlich validiert werden, bevor Sie sich für eine aktive/aktive Bereitstellung entscheiden. Außerdem müssen Sie die Erkennung und Behebung von Konflikten berücksichtigen.

Im Gegensatz zu Data Guard erfordert GoldenGate die Installation und Wartung zusätzlicher Software auf den Oracle-Datenbankservern. Für aktive/aktive Bereitstellungen ist in der Regel ein ausgefeiltes Schema- und Anwendungsdesign erforderlich, um die Vorteile einer Bereitstellung von Datenbanken an mehreren Standorten zu nutzen. Viele vorkonfigurierte Anwendungen unterstützen diese Art von Architektur nicht.

Bereitstellungen, die für die gesamte Replikation auf GoldenGate angewiesen sind, können aufgrund der asynchronen Natur der logischen Replikation keine RPO von null Datenverlusten unterstützen. Lokale Standby-Datenbanken, die in der Compute Engine mit Data Guard ausgeführt werden, können bereitgestellt werden, um bei synchroner Replikation einen RPO von null zu erreichen.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Oracle Platinum-Bereitstellung GoldenGate für die Replikation.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Wiederherstellbarer Knoten- oder Instanzfehler 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Beschädigungen Sekunden in Minuten umrechnen

0, wenn an jedem Standort Data Guard verwendet wird

 0
Katastrophen: Ausfälle bei der Regionenerweiterung Sekunden in Minuten umrechnen

0, wenn an jedem Standort Data Guard verwendet wird

 0
Geplant Datenbank-Patches, Betriebssystem-/Firmwareupdates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist.

Sekunden bei Verwendung von RAC
Großes Datenbank-Upgrade 0 0