Optionen für die Notfallwiederherstellung von Oracle-Datenbankarbeitslasten

In diesem Leitfaden werden die Notfallwiederherstellungsoptionen beschrieben, die Nutzern zur Verfügung stehen. Ausführen geschäftskritischer Arbeitslasten von Oracle-Datenbanken in einer Bare-Metal-Lösung zu verbessern.

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. Einige dieser Funktionen umfassen, sind aber nicht beschränkt in:

  • 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 das Recovery Time Objective (RTO) und das Recovery Point Objective einer Anwendung (RPO). Im Allgemeinen beschreibt RTO die akzeptable Ausfallzeit eines Systems. und RPO die Menge des Datenverlusts beschreibt, die akzeptabel ist. Die Kosten und die Komplexität eines Systems zunimmt, je mehr dieser Werte abnimmt. Weitere Informationen Informationen zu RTO und RPO finden Sie unter Grundlagen der DR-Planung.

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.

Sofern in der Designphase nicht ordnungsgemäß berücksichtigt, wird die Implementierung von Nulldaten Verlustarchitektur kann sich nachteilig auf die Gesamtleistung der Anwendung auswirken.

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. Eine Katastrophe die Wiederherstellung ist Teil eines Gesamtplanes zur Aufrechterhaltung des Geschäftsbetriebs und die ganze Gruppen von Systemen nicht verfügbar machen. Notfallwiederherstellung umfasst einen größeren Umfang aufgrund der Anzahl integrierter Komponenten, die im Notfall wiederhergestellt werden.

Die Hochverfügbarkeit muss bei der Entwicklung eines zuverlässigen Systems als „erste Verteidigungslinie“ betrachtet werden. Eine hochverfügbare Datenbankarchitektur muss einzelne Ausfälle aufrechterhalten und den Betrieb ohne Ausfallzeiten für der Anwendung. Die Hochverfügbarkeitskomponenten eines Systems müssen sind nicht auf Folgendes beschränkt:

  • Redundante Stromversorgung zu 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 Serverausfälle 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-Anwendungscluster

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 Region .

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ösungs-Pod vorhanden sein. Damit ist RAC eine Lösung für Hochverfügbarkeit. Bedenken hinsichtlich der Notfallwiederherstellung, erfüllt aber nicht die Anforderung der Notfallwiederherstellung.

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

Oracle-Wiederherstellungsmanager

Oracle Recovery Manager (RMAN) ist das primäre Tool für die Sicherung und Wiederherstellung Oracle-Datenbanken, da diese die proprietäre Datendatei von Oracle lesen können Format. Sie können damit Datenbankklone, die Wiederherstellung zu einem bestimmten Zeitpunkt die Wiederherstellung einer einzelnen Tabelle in einer Oracle-Datenbank.

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

Oracle Data Guard

Oracle Data Guard führt die Datenbankreplikation auf Remote-RAC-Cluster oder andere Datenbankinstallationen aus. Data Guard unterstützt Standby-Datenbanken in physische oder logische 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 Datenbank schneller wiederherzustellen. 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 für Aktivierung von Aktiv/Aktiv-Bereitstellungen an mehreren Standorten oder Verschieben von Daten auf Hardware Plattformen. Bei Verwendung von GoldenGate ein extract-Prozess für die Quelldatenbank erfasst Änderungen in den Online-Redo-Logs und schreibt diese in Änderungen, -Dateien, die in die Zieldatenbank übertragen werden. Ein replicat-Prozess im wandelt Transaktionen aus den Tail-Dateien in SQL um SQL für die Zieldatenbank.

Diese Architektur macht GoldenGate zu einem leistungsfähigen Tool zum Verschieben von Daten zwischen oder Daten bei der Replikation transformieren. Im Gegensatz zu Data Guard Für GoldenGate muss eine separate Software auf dem Quell- und Zielsysteme. GoldenGate kann nicht für die synchrone Replikation verwendet werden da Transaktionen als SQL übersetzt und auf dem Zieldatenbank. GoldenGate kann zwar eine minimale Verzögerung bei der Replikation bieten, allein kann GoldenGate jedoch kein RPO von null garantieren.

Bereitstellungsmodelle für die Notfallwiederherstellung (nur Datenbanken)

Oracle hat das MAA-Framework (Maximum Availability Architecture) entwickelt, erhalten Sie empfohlene Notfallwiederherstellungsmodelle für das Deployment Ihres Anwendungen und Datenbanken.

Jedes der folgenden Modelle bietet bestimmte RTO- und RPO-Ziele:

Die Modelle werden bestimmten Bereitstellungsmustern zugeordnet, die den RPO- und RTO-Werten entsprechen. bei geplanten und ungeplanten Ausfällen. Jede Datenbankarbeitslast muss auf Verfügbarkeitsanforderungen geprüft und mit einer entsprechenden modellieren. Für Entwicklungsdatenbanken wird häufig ein Modell mit einem niedrigeren Schutzniveau verwendet als für Produktions- und QA-Entsprechungen.

Das Bronze-Modell ist für Datenbanken gedacht, für die keine RTO in Minuten erforderlich ist. Die Silber- und übergeordneten Modelle umfassen Standby-Datenbanken, die in eine Remote-Website. Jedes Modell verfügt über die Funktionen der Modelle. Das Bronze-Modell nutzt beispielsweise Sicherungs- und Wiederherstellungskonzepte, selbst wenn eine Standby-Datenbank bereitgestellt wird.

Kupfermodell

Das Copper-Modell bietet eine minimale Bereitstellung, um Datenbanken im lokalen Speicher zu sichern und in einen Speicher 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, daher müssen sie an einen Standort für RMAN verfügbar, bevor die Wiederherstellung beginnen kann.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Fehler bei wiederherstellbarem Knoten oder Instanz 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Korruption Zuletzt erstelltes Archivelog, inkrementelles oder vollständiges Backup aus dem RE Stunden, je nach Datenbankgröße und der zugewiesenen Bandbreite Partner Interconnect
Katastrophen: Ausfälle bei der Regionenerweiterung Letztes Archivprotokoll, letzte inkrementelle oder letzte vollständige Sicherung, die aus dem RE übertragen wurde Tage / Wochen, abhängig von der Zeit, die erforderlich ist, um die Regionserweiterung wieder online zu schalten
Geplant Datenbank-Patches, Betriebssystem-/FW-Updates 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 ist Cloud Storage mit Cloud Storage FUSE das bevorzugte Sicherungsziel. Cloud Storage-Bucket als Dateisystem dargestellt.

Die Empfehlungen zur Verwendung von Cloud Storage FUSE finden Sie in 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 Fehler bei wiederherstellbarem Knoten oder Instanz 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Beschädigungen Letztes Archivprotokoll, inkrementelles oder vollständiges Backup Stunden, je nach Datenbankgröße und der zugewiesenen Bandbreite Partner Interconnect
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 Dienst für Sicherung und Notfallwiederherstellung verwendet, um Sicherungen in Google Cloud 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 bietet außerdem ein schnelleres RTO als das Speichern von Filestore oder Cloud Storage verwenden, da er sofort Images von Datenbankdateien, die für die Oracle-Instanz verfügbar sind. Die Bereitstellung und Migration bringt eine Datenbank schnell online, während sie zurück in die Produktion kopiert wird und reduziert so die RTO drastisch.

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

Bronze-Bereitstellung von Google Cloud Backup and DR

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Fehler bei wiederherstellbarem Knoten oder Instanz 0 Erforderliche Zeit für den Neustart der Instanz

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen Letztes Archivprotokoll, inkrementelles oder vollständiges Backup Minuten bis Stunden, je nach Leistungsanforderungen, Datenbankgröße und der zugewiesenen Bandbreite Partner Interconnect
Katastrophen: Ausfälle der Regionserweiterung Letztes Archivprotokoll, inkrementelles oder vollständiges Backup 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-/FW-Updates 0 Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
Großes Datenbank-Upgrade 0 1–2 Stunden

Silber

Beim Silber-Modell wird die Datenbankreplikation mithilfe von 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. The Silver auf asynchroner Replikation basiert. mit synchroner Replikation sicher, Es gibt keinen Datenverlust, aber die Zeit, die für das Senden von Daten zwischen Regionen benötigt wird, die Antwortzeit der Anwendung über die akzeptablen Grenzen hinausgeht.

Die Data Guard-Funktion für den Schnellstart-Failover kann automatische Failover-Vorgänge, wenn eine primäre Datenbank für eine bestimmte benutzerdefinierten Zeitraum. 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 jedoch die Anwendungsleistung beeinträchtigen, da sich die Netzwerklatenz zwischen den Anwendungsservern und der Datenbank erhöht. 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 Silber-Modell kann es dennoch zu Ausfallzeiten oder Wartungsfenstern kommen während der vierteljährlichen Patching-Aktivitäten. 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. Replikation wird asynchron konfiguriert Data Guard. Gesamter Traffic zwischen der Bare-Metal-Lösung und Google Cloud ein Partner Interconnect durchläuft und regionenübergreifenden Traffic durchläuft über das Backbone des Google-Netzwerks. 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 Fehler bei wiederherstellbarem Knoten oder Instanz 0 Erforderliche Zeit für den Neustart der Instanz

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen < 60 Sek. Minuten bis Stunden, je nach Anwendungs-Failover.
Katastrophen: Ausfälle bei der Regionenerweiterung < 60 Sek. Minuten bis Stunden, je nach Anwendungs-Failover.
Geplant Datenbank-Patches, Betriebssystem-/FW-Updates 0 Erforderliche Zeit zum Aktualisieren und Neustarten der Instanz.

Sekunden bei Verwendung von RAC
Wichtiges Datenbankupgrade 0 1–2 Stunden

Minuten, wenn das Upgrade mit DBMS_ROLLING durchgeführt wird.

Gold-Modell

Wenn Sie Bedenken hinsichtlich des Datenverlusts im Silber-Modell haben, können Sie entscheiden Sie sich für das Gold-Modell, das eine Instanz der weitreichenden Synchronisierung verwendet zur synchronen Replikation einer Instanz, die in Google Cloud ausgeführt wird Compute Engine

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 Hosting ausgewählt. weiter synchronisierte Instanz. 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 durch Anwendungen, die in Compute Engine ausgeführt werden. Compute Engine Instanz in us-west2 führt eine weit synchronisierte Instanz aus und empfängt synchrone „Wiederholen“. 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 Fehler bei wiederherstellbarem Knoten oder Instanz 0 Erforderliche Zeit für den Neustart der Instanz

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen 0 Minuten bis Stunden, je nach regionalem Failover der Anwendung.
Katastrophen: Ausfälle der Regionserweiterung 0 Minuten bis Stunden, je nach regionalem Failover der Anwendung.
Geplant Datenbank-Patches, Betriebssystem-/FW-Updates 0 Erforderliche Zeit zum Aktualisieren und Neustarten der Instanz.

Sekunden bei Verwendung von RAC
Wichtiges Datenbankupgrade 0 1–2 Stunden

Minuten, wenn das Upgrade mit DBMS_ROLLING durchgeführt wird.

Platinmodell

Das Platin-Modell bietet zwei Bereitstellungsoptionen. Jede Bereitstellungsoption bietet mit einer anderen Technologie schützen und unterschiedliche RTO- und RPO-Werte Eigenschaften.

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

Die Platin-Bereitstellung 1 baut auf der Gold-Modellbereitstellung auf Hinzufügen einer zweiten Data Guard-Standby-Datenbank in der lokalen Region, die auf einem Compute Engine-Instanz. Diese Konfiguration verwendet die synchrone Replikation zwischen der primären Datenbank und dem Standby-Modus, der in Compute Engine ausgeführt wird, sodass in der primären Region kein Datenverlust garantiert wird.

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. Während der Datenbankrolle und Anwendungen, die gemäß den Die Hinweise zum Oracle-Client stellen automatisch wieder eine Verbindung zur neuen primären Datenbank her, ohne manuelles Eingreifen erforderlich. Richtig konfigurierte Anwendungen als 2 Minuten Ausfallzeit während eines Failover-Ereignisses.

Auch wenn die Stand-by-Datenbank in Compute Engine kein RAC ausführt, angepasst, um den normalen Anwendungstraffic zu unterstützen, wenn er als primäre Instanz ausgeführt wird Datenbank. 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.

Der Schnellstart-Failover ist auf einer Compute Engine-Instanz konfiguriert, auf der die Data Guard-Broker mit einem Beobachter. 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 Compute Engine ausgeführte Standby-Datenbank als bevorzugtes Failover-Ziel konfiguriert, wenn Sie die Bereitstellung der Stufe „Gold“ verwenden.

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 regionale Ausfälle und Netzwerkpartitionierungsereignisse. Wenn eine dritte Region nicht muss der Beobachter in der primären Region installiert sein, eine andere Zone als die Nah-Standort-Standby-Zone.

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

Oracle Platinum-Bereitstellung von Data Guard mit schnellem Failover

Die im Diagramm gezeigte Beispielbereitstellung umfasst Folgendes:

  • Eine primäre Datenbank, die RAC auf dem Server der Bare-Metal-Lösung in us-west2 ausführt Region
  • Eine standortnahe Standby-Datenbank, die auf einer Compute Engine-Instanz in us-west2.
  • Eine Remote-Standby-Datenbank, die auf dem Server der Bare-Metal-Lösung in us-east4 ausgeführt wird Region
  • 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 „Wiederholen“ von der primären Datenbank an die Standby; wird „redo“ nicht von einer Stand-by-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 Falle eines Notfalls zu verarbeiten.

Ausfall Art des Ausfalls RPO RTO
Nicht geplant Fehler bei wiederherstellbarem Knoten oder Instanz 0 Erforderliche Zeit für den Neustart der Instanz

Sekunden bei Verwendung von RAC
Katastrophen: Beschädigungen 0 < 60 Sek.
Katastrophen: Ausfälle bei der Regionenerweiterung 0 &lt; 60er
Geplant Datenbank-Patches, Betriebssystem-/FW-Updates 0 Erforderliche Zeit zum Aktualisieren und Neustarten der Instanz.

Sekunden bei Verwendung von RAC
Wichtiges Datenbankupgrade 0 1–2 Stunden

Minuten, wenn das Upgrade mit DBMS_ROLLING durchgeführt wird.

Platin-Deployment 2: GoldenGate für Replikation

Bei der Platin-Bereitstellung 2 wird Oracle GoldenGate für die Replikation verwendet. Da GoldenGate nicht auf Blockebene repliziert. So kann jede Datenbank Lese- und Schreibzugriff auf Anwendungssitzungen durch einen Dienst. Die Änderungen werden bidirektional repliziert, was eine Aktiv/Aktiv-Datenbankkonfiguration ermöglicht.

Anträge müssen gründlich validiert werden. bevor Sie einen aktiven/aktiven Bereitstellung und Sie müssen die Konflikte erkennen und beheben.

Im Gegensatz zu Data Guard erfordert GoldenGate die Installation und Wartung zusätzliche Software auf den Oracle-Datenbankservern. Aktive/aktive Bereitstellungen erfordern in der Regel ein ausgefeiltes Schema- und Anwendungsdesign, um einer Datenbankbereitstellung mit mehreren Standorten. 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. Lokal Stand-by-Datenbanken, die in Compute Engine mit Data Guard ausgeführt werden, können bereitgestellt werden. um ein RPO von null mit synchroner Replikation bereitzustellen.

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 Fehler bei wiederherstellbarem Knoten oder Instanz 0 Zeit, die für den Neustart der Instanz erforderlich ist
Katastrophen: Korruption Sekunden in Minuten umrechnen

0, wenn Data Guard an jedem Standort verwendet wird

 0
Katastrophen: Ausfälle der Regionserweiterung Sekunden in Minuten umrechnen

0, wenn Data Guard an jedem Standort verwendet wird

 0
Geplant Datenbank-Patches, Betriebssystem-/FW-Updates 0 Erforderliche Zeit zum Aktualisieren und Neustarten der Instanz.

Sekunden bei Verwendung von RAC
Wichtiges Datenbankupgrade 0 0