Disaster Recovery für MySQL HeatWave mit Replikationskanälen mit OCI Full Stack Disaster Recovery automatisieren

Einführung

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestriert den Übergang von Compute-, Datenbank- und Anwendungen zwischen OCI-Regionen aus der ganzen Welt mit einem einzigen Klick. Kunden können die erforderlichen Schritte zur Wiederherstellung eines oder mehrerer Geschäftssysteme automatisieren, ohne die vorhandene Infrastruktur, Datenbanken oder Anwendungen neu zu entwerfen oder zu strukturieren und ohne spezielle Verwaltungs- oder Konvertierungsserver zu benötigen.

MySQL HeatWave ist ein vollständig verwalteter Datenbankservice, der in Oracle Cloud Infrastructure (OCI) bereitgestellt wird und Betreiber und Entwickler unterstützt, die schnell sichere, cloudnative Anwendungen bereitstellen möchten. MySQL HeatWave ist das einzige MySQL-Angebot, das die Verwendung von HeatWave, einem integrierten, leistungsstarken In-Memory-Abfragebeschleuniger, umfasst. Mit HeatWave können Kunden anspruchsvolle Analysen direkt in ihrer betrieblichen MySQL-Datenbank ausführen, sodass keine komplexe, zeitaufwendige und teure Datenmigration und -integration mit einer separaten Analysedatenbank erforderlich ist. HeatWave beschleunigt die MySQL-Performance für Analysen und gemischte Workloads enorm. HeatWave ist vollständig für OCI optimiert, und MySQL HeatWave wird zu 100% von den OCI- und MySQL-Engineering-Teams erstellt, verwaltet und unterstützt.

In diesem Tutorial erfahren Sie, wie Sie Disaster-Recovery-Pläne für MySQL HeatWave in OCI mit Kanalreplikation automatisieren. Es beschreibt die Verfahren zur Verwendung von OCI Full Stack DR, die jetzt nativ MySQL HeatWave unterstützt, um Switchover- und Failover-Vorgänge zu verwalten.

Architekturbeschreibung

Die in diesem Tutorial dargestellte Architektur zeigt MySQL HeatWave, bei der die eingehende Replikation verwendet wird, um die asynchrone Datenreplikation zwischen dem primären Datenbanksystem und einem Remotereplikat zu ermöglichen und eine effiziente Datensynchronisierung über Regionen hinweg sicherzustellen.

Beschreibung der Abbildung full-stack-disaster-recovery-heatwave.png

Hinweis: Für das MySQL HeatWave-Replikat in der Disaster-Recovery-Region muss der Modus Schreibgeschützt aktiviert sein, um die Datenintegrität sicherzustellen und unbeabsichtigte Änderungen zu verhindern.

Voraussetzungen (Benutzervorbereitung)

Bevor Sie das Replikationssetup initiieren, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind. Dazu gehören sowohl replikationsspezifische Anforderungen als auch zusätzliche Infrastruktur- und Konfigurationsvoraussetzungen, die erforderlich sind, um eine robuste Full Stack Disaster Recovery-(FSDR-)Architektur für MySQL HeatWave auf Oracle Cloud Infrastructure (OCI) zu unterstützen.

• Netzwerkkonnektivität
  Stellen Sie eine sichere Kommunikation zwischen der Quell- und der Zielregion her, indem Sie:
  • Dynamische Routinggateways (DRGs)
  • Remote-Peering-Verbindungen
• Netzwerkkonfiguration
  Konfigurieren Sie Folgendes, um regionsübergreifenden MySQL-Traffic zuzulassen:
  • Sicherheitslisten** oder **Netzwerksicherheitsgruppen (NSGs)
  • Routingtabellen
• Full Stack Disaster Recovery Konfigurieren Sie die erforderlichen OCI-IAM-Policys für OCI Full Stack DR, wie in den folgenden Dokumenten beschrieben.
  • Policys für OCI Full Stack DR
  • Identity and Access Management-(IAM-)Policys zur Verwendung von Full Stack DR konfigurieren

  OCI Full Stack DR muss in der Lage sein, andere wichtige OCI-Services wie Compute, Networking, Storage und andere verschiedene Services zu kontrollieren und zu verwalten. Informationen zum Konfigurieren der erforderlichen OCI-IAM-Policys für andere Services finden Sie unter Policys für andere Services, die von Full Stack Disaster Recovery verwaltet werden und OCI-IAM-Policys.

  Hinweis: für MySQL HeatWave

  Als Voraussetzung für die Konfiguration von MySQL HeatWave mit FSDR müssen OCI Vault Secrets in beiden Regionen erstellt werden. In diesen Secrets müssen das Admin-Benutzerkennwort und das Replikationsbenutzerkennwort sicher gespeichert werden.

MySQL HeatWave-Systemsetup - High-Level-Übersicht

Im Folgenden finden Sie eine allgemeine Zusammenfassung der Schritte, die zum Einrichten der regionalen Replikation für MySQL HeatWave auf Oracle Cloud Infrastructure (OCI) erforderlich sind, um eine sichere, zuverlässige und skalierbare Datensynchronisierung über Regionen hinweg sicherzustellen.

• Stellen Sie ein primäres MySQL HeatWave in der Quellregion bereit.
• Erstellen Sie einen Replikationsbenutzer auf dem MySQL-Quellserver mit den entsprechenden Berechtigungen.
• Erstellen Sie manuell ein Backup der Primärdatenbank.
• Kopieren Sie das Backup mit dem OCI-Feature Backup kopieren in die Zielregion.
• Wiederherstellen Sie das Backup in der Zielregion, um ein neues Standby-DB-System zu erstellen.
• Ändern Sie den Modus des Standby-DB-Systems in Schreibgeschützt.
• Richten Sie in der Zielregion den Replikationskanal wie folgt ein:
  • Quell-DB-Hostname, Port
  • Replikationsbenutzerzugangsdaten
• Überwachen Sie den Replikationsstatus regelmäßig in der Ziel-DB MySQL.
• Führen Sie Datenkonsistenzprüfungen durch, um zu prüfen, ob die Replikation korrekt ist und die Datenintegrität aufrechterhalten wird.

Wenn Sie diese Schritte ausführen, können Sie ein robustes regionsübergreifendes Replikationssetup für MySQL auf OCI implementieren und so die Resilienz und Verfügbarkeit Ihrer Anwendung über geografische Regionen hinweg verbessern.

Hinweis: Das folgende Tutorial: Regionsübergreifende MySQL HeatWave-Disaster-Recovery-Kopie in OCI einrichten bietet einen umfassenden Leitfaden für das Deployment von Disaster Recovery für das Datenbanksystem MySQL, um Resilienz und Kontinuität bei Systemfehlern sicherzustellen.

Definitionen und Annahmen im gesamten Tutorial

• Bereiche:

  • Region 1 ist Ashburn: Ashburn dient zunächst als primäre Region. Diese Rolle wird jedoch während des Switchover-Prozesses in den Standby-Modus versetzt, der in den späteren Aufgaben im Rahmen des Disaster Recovery-Plans ausgeführt wird.

  • Region 2 ist Phoenix: Phoenix fungiert zunächst als Standbyregion. Diese Rolle wird im Anschluss an den Switchover-Prozess, der in den nachfolgenden Aufgaben im Rahmen des Disaster-Recovery-Verfahrens durchgeführt wird, später zur primären Rolle übergehen.

• Compartments: Sie können dieses Deployment und OCI Full Stack DR in jedem Compartment-Schema organisieren, das gemäß Ihren Standards für IT-Governance funktioniert. Wir haben uns entschieden, alle OCI-Ressourcen für dieses Tutorial in einem einzigen Compartment zu organisieren.

Ziele

In diesem Tutorial werden die folgenden Aufgaben behandelt:

1. Aufgabe 1: DR-Schutzgruppen (DRPG) in beiden Regionen erstellen
2. Aufgabe 2: MySQL HeatWave zu den DR-Schutzgruppen in beiden Regionen hinzufügen
3. Aufgabe 3: DR-Pläne in Teilsektor 2 erstellen
4. Aufgabe 4: Vorabprüfungen der DR-Pläne in Region 2 ausführen
5. Aufgabe 5: Switchover-Plan in Region 2 ausführen
6. Aufgabe 6: DR-Pläne in Teilsektor 1 erstellen

Aufgabe 1: DR-Schutzgruppen (DRPG) in beiden Regionen erstellen

Erstellen Sie DR-Schutzgruppen in Region 1 und Region 2, wenn die Schutzgruppen für diesen Anwendungsstack noch nicht vorhanden sind.

Aufgabe 1.1: Schutzgruppe in Region 1 erstellen

1. Gehen Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen, wie in Abbildung 1.1 dargestellt.

   1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) gesetzt ist.
   2. Klicken Sie auf Migration und Disaster Recovery.
   3. Klicken Sie auf DR-Schutzgruppen.

   
   Abbildung 1.1: Zu DR-Schutzgruppen navigieren

2. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.

   
   Abbildung 1.2: Klicken Sie auf "DR-Schutz erstellen".

3. Erstellen Sie eine grundlegende DR-Schutzgruppe (DRPG) in Region 1, wie in Abbildung 1.3 dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.

   1. Verwenden Sie einen aussagekräftigen Namen für das DRPG.
   2. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll.
   3. Wählen Sie den OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
   4. Klicken Sie auf Erstellen.

   
   Abbildung 1.3: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 1

Aufgabe 1.2: Schutzgruppe in Region 2 erstellen

1. Navigieren Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen, wie in Abbildung 1.4 dargestellt.

   1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 2 (Phoenix) gesetzt ist.
   2. Klicken Sie auf Migration und Disaster Recovery.
   3. Klicken Sie auf DR-Schutzgruppen.

   
   Abbildung 1.4: Zu DR-Schutzgruppen navigieren

2. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.

   
   Abbildung 1.5: Klicken Sie auf "DR-Schutz erstellen".

3. Erstellen Sie eine DR-Schutzgruppe (DRPG) in Region 2, wie in Abbildung 1.6 dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.

   1. Verwenden Sie einen aussagekräftigen Namen für das DRPG.
   2. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll.
   3. Wählen Sie den OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
   4. Klicken Sie auf Erstellen.

   
   Abbildung 1.6: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 2

Aufgabe 1.3: Schutzgruppen in Region 1 und Region 2 zuordnen

Verknüpfen Sie die DRPGs in jeder Region als Peers untereinander, und weisen Sie die Peerrollen von Primär- und Standbydatenbank zu. Die Rollen von Primär- und Standbydatenbank werden automatisch von OCI Full Stack DR im Rahmen einer DR-Operation/DR-Planausführung geändert. Die Rollen müssen nicht jederzeit manuell verwaltet werden.

1. Gehen Sie zur Seite DR-Schutzgruppendetails.

   1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) gesetzt ist.
   2. Klicken Sie auf Aktion
   3. Klicken Sie auf Zuordnen, um den Prozess zu starten.

   
   Abbildung 1.7: DRPG-Verknüpfung beginnen

2. Geben Sie die Parameter wie in der folgenden Abbildung dargestellt ein.

   1. Rolle: Wählen Sie die Rolle Primär aus. OCI Full Stack DR weist Region 2 automatisch die Standbyrolle zu.
   2. Peerregion: Wählen Sie Region 2 (Phoenix) aus, in der das andere DRPG erstellt wurde.
   3. Peer-DR-Schutzgruppe: Wählen Sie das erstellte Peer-DRPG aus.
   4. Klicken Sie auf Verknüpfen.

   
   Abbildung 1.8: Erforderliche Parameter für die Zuordnung der DRPGs

3. Lassen Sie zu, dass die Arbeitsanforderung abgeschlossen wird, bevor Sie fortfahren.

   
   Abbildung 1.9: DRPG-Verknüpfung abgeschlossen.

OCI Full Stack DR zeigt so etwas wie in der folgenden Abbildung, sobald die Verknüpfung abgeschlossen ist.

1. Die aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
2. Die aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 1.10: Peer-Beziehung aus der individuellen DRPG-Perspektive anzeigen

Die gleichen Informationen finden Sie, wenn der Kontext/die Ansicht aus einer globalen Perspektive alle DR-Schutzgruppen zeigt, wie im folgenden Bild gezeigt.

1. Die aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
2. Die aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 1.11: Peer-Beziehung aus globaler DRPG-Perspektive anzeigen

Aufgabe 2: MySQL HeatWave zur DR-Schutzgruppe hinzufügen

Aufgabe 2.1: MySQL HeatWave zu DRPG in Region 1 hinzufügen

1. Wählen Sie das DRPG in Region 1 aus, wie in der folgenden Abbildung dargestellt.

   1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Ashburn) ist.
   2. Wählen Sie das DRPG in Region 1 aus.
   3. Wählen Sie Elemente aus.
   4. Klicken Sie auf Mitglieder verwalten, um den Prozess zu starten.

   
   Abbildung 2.1: So fügen Sie Mitglieder zur DR-Schutzgruppe in Region 1 hinzu

2. Klicken Sie auf Mitglied hinzufügen.

   
   Abbildung 2.2: Beginnen Sie mit dem Hinzufügen von Elementen zur DR-Schutzgruppe in Region 1

3. Fügen Sie die MySQL HeataWave zum DRPG in Region 1 hinzu.

   1. Geben Sie MySQL Database System als Element-Ressourcentyp ein.
   2. Wählen Sie das entsprechende Compartment aus, und wählen Sie dann den primären MySQL HeatWave-Namen in Region 1 im Feld Datenbanksystem aus.
   3. Wählen Sie das entsprechende Compartment und dann den Replikat-MySQL HeatWave-Namen in Region 2 aus dem Feld Peer-Datenbanksystem aus.
   4. Geben Sie den Admin-Benutzernamen ein.
   5. Wählen Sie das entsprechende Compartment aus, und wählen Sie das Admin-Kennwort-Secret aus.
   6. Geben Sie den Replikationsbenutzernamen ein.
   7. Wählen Sie das entsprechende Compartment aus, und wählen Sie das Replikationskennwort-Secret aus.
   8. Klicken Sie auf Hinzufügen.

   Optionale Parameter:

   • Abstimmungs-Timeout: Gibt die Zeit in Sekunden an, die auf die Synchronisierung der globalen Transaktions-ID (GTID) während des Abstimmungsprozesses gewartet wird. Diese Timeout-Einstellung stellt sicher, dass das System ausreichend Zeit für die GTID-Synchronisierung zulässt, bevor der Vorgang als nicht erfolgreich oder abgeschlossen betrachtet wird.
   • Weiter bei Abstimmungstimeout: Wenn Sie diese Option aktivieren, wird der GTID-Validierungsprozess umgangen, sobald der Timeout überschritten wurde. Dadurch kann der Failover oder Switchover fortgesetzt werden, auch wenn die GTID-Synchronisierung unvollständig ist.

   
   Abbildung 2.3: Erforderliche Parameter zum Hinzufügen von MySQL HeatWave

4. Änderungen in der DRPG-Region 1 veröffentlichen

   Klicken Sie auf Änderungen veröffentlichen.
   Abbildung 2.4: Änderungen veröffentlichen

   Bestätigen Sie, indem Sie auf Änderungen veröffentlichen
   Abbildung 2.4: Änderungen veröffentlichen

   
   Abbildung 2.5: MySQL HeatWave wurde dem DRPG in Region 1 hinzugefügt.

Aufgabe 2.2: MySQL HeatWave zu DRPG in Region 2 hinzufügen

1. Wählen Sie das DRPG in Region 2 aus, wie in der folgenden Abbildung dargestellt.

   1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
   2. Wählen Sie das DRPG in Region 2 aus.
   3. Wählen Sie Elemente aus.
   4. Klicken Sie auf Mitglieder verwalten, um den Prozess zu starten.

   
   Abbildung 2.6: So fügen Sie Mitglieder zur DR-Schutzgruppe in Region 2 hinzu

2. Klicken Sie auf Mitglied hinzufügen.

   
   Abbildung 2.7: Beginnen Sie mit dem Hinzufügen von Elementen zur DR-Schutzgruppe in Region 2

3. Fügen Sie die MySQL HeataWave zum DRPG in Region 2 hinzu.

   1. Geben Sie MySQL Database System als Element-Ressourcentyp ein.
   2. Wählen Sie das entsprechende Compartment aus, und wählen Sie dann den Replikat-MySQL HeatWave-Namen in Region 2 im Feld Datenbanksystem aus.
   3. Wählen Sie das entsprechende Compartment aus, und wählen Sie dann den primären MySQL HeatWave-Namen in Region 1 im Feld Peer-Datenbanksystem aus.
   4. Geben Sie den Admin-Benutzernamen ein.
   5. Wählen Sie das entsprechende Compartment aus, und wählen Sie das Admin-Kennwort-Secret aus.
   6. Geben Sie den Replikationsbenutzernamen ein.
   7. Wählen Sie das entsprechende Compartment aus, und wählen Sie das Replikationskennwort-Secret aus.
   8. Klicken Sie auf Hinzufügen.

   Optionale Parameter:

   • Abstimmungs-Timeout: Gibt die Zeit in Sekunden an, die auf die Synchronisierung der globalen Transaktions-ID (GTID) während des Abstimmungsprozesses gewartet wird. Diese Timeout-Einstellung stellt sicher, dass das System ausreichend Zeit für die GTID-Synchronisierung zulässt, bevor der Vorgang als nicht erfolgreich oder abgeschlossen betrachtet wird.
   • Weiter bei Abstimmungstimeout: Wenn Sie diese Option aktivieren, wird der GTID-Validierungsprozess umgangen, sobald der Timeout überschritten wurde. Dadurch kann der Failover oder Switchover fortgesetzt werden, auch wenn die GTID-Synchronisierung unvollständig ist.

   
   Abbildung 2.8: Erforderliche Parameter zum Hinzufügen von MySQL HeatWave

4. Veröffentlichen Sie die Änderungen in der DRPG-Region 2.

   Klicken Sie auf Änderungen veröffentlichen.
   Abbildung 2.9: Änderungen veröffentlichen

   Bestätigen Sie, indem Sie auf Änderungen veröffentlichen klicken.
   Abbildung 2.10: Änderungen veröffentlichen

   
   Abbildung 2.11: MySQL HeatWave wurde dem DRPG in Region 2 hinzugefügt

Aufgabe 3: DR-Pläne in Teilsektor 2 erstellen

In dieser Aufgabe erstellen wir die anfänglichen Switchover- und Failover-Pläne, die der Standby-DR-Schutzgruppe in Region 2 (Phoenix) zugeordnet sind.

Der Zweck dieser Pläne besteht darin, die Workload nahtlos von der primären Region (Region 1) in die Standby-Region (Region 2) zu übertragen. Im Rahmen eines DR-Vorgangs werden die Rollen der DR-Schutzgruppen in beiden Regionen automatisch umgekehrt: Die Schutzgruppe in Region 1 wird zur Standby-Gruppe, während die Schutzgruppe in Region 2 nach einem Failover oder Switchover die primäre Rolle übernimmt.

OCI Full Stack DR füllt diese Pläne vorab mit integrierten Schritten aus, die von den Member-Ressourcen abgeleitet werden, die während der vorherigen Aufgaben hinzugefügt wurden. Die DR-Pläne werden automatisch mit den entsprechenden MySQL HeatWave-Wiederherstellungsaufgaben vorab aufgefüllt, da MySQL HeatWave in Full Stack Disaster Recovery integriert ist.

DR-Pläne werden immer innerhalb der Schutzgruppe mit der Standby-Rolle erstellt. Da Region 2 (Phoenix) derzeit die Standby-Schutzgruppe ist, erstellen wir die Pläne dort.

Aufgabe 3.1: DR-Pläne erstellen

1. Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 2 (Phoenix) auswählen

   1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
   2. Wählen Sie das Standby-DRPG in Region 2.
   3. Wählen Sie Plans aus.
   4. Klicken Sie auf Plan erstellen, um den Prozess zu starten.

   
   Abbildung 3.1: Grundlegende DR-Pläne in Region 2 erstellen

2. Switchover-Plan erstellen

   1. Geben Sie einen einfachen, aber aussagekräftigen Namen für den Switchover-Plan ein. Der Name sollte so kurz wie möglich, aber leicht auf einen Blick zu verstehen sein, um Verwirrung und menschliche Fehler während einer Krise zu reduzieren.
   2. Wählen Sie Plantyp als Switchover (geplant) aus.

   
   Abbildung 3.2: Die Parameter, die zum Erstellen eines DR-Switchover-Plans erforderlich sind

   
   Abbildung 3.3: DR-Switchover-Plan

   Klicken Sie auf den DR-Plannamen, um die DR-Plandetails und die Plangruppen anzuzeigen.
   Abbildung 3.4: MySQL HeatWave-Plangruppe für DR-Switchover

3. Failover-Plan erstellen

   1. Geben Sie einen einfachen, aber aussagekräftigen Namen für den Failover-Plan ein. Der Name sollte so kurz wie möglich, aber leicht auf einen Blick zu verstehen sein, um Verwirrung und menschliche Fehler während einer Krise zu reduzieren.
   2. Wählen Sie Plantyp als Failover (ungeplant) aus.

   
   Abbildung 3.5: Die Parameter, die zum Erstellen eines DR-Failover-Plans erforderlich sind

   
   Abbildung 3.6: DR-Failover-Plan

   Klicken Sie auf den DR-Plannamen, um die DR-Plandetails und die Plangruppen anzuzeigen.
   Abbildung 3.7: DR-Failover MySQL HeatWave-Plangruppe

Die Standby-DR-Schutzgruppe in Region 2 sollte jetzt über die beiden DR-Pläne verfügen. Diese verarbeiten den Übergang von Workloads von Region 1 zu Region 2.

Hinweis: Nach der ersten Ausführung des Switchover-Plans erstellen wir später entsprechende Pläne in Region 1, um Workloads von Region 2 zurückzusetzen.

1. (Optional) DR-Drill-Pläne erstellen - Drill-Vorgänge starten und stoppen

Genau wie Switchover- und Failover-Pläne können Sie einen DR-Plan für Drilldown starten erstellen. Während des Drilldown starten wird ein neues DB-System mit den neuesten verfügbaren Backups erstellt. Dabei wird ein echtes Disaster-Recovery-Szenario simuliert, bei dem Sie Vorgänge in der DR-Region wiederherstellen müssen.

1. Geben Sie einen einfachen, aber aussagekräftigen Namen für den Plan Drilldown starten ein. Der Name sollte so kurz wie möglich, aber leicht auf einen Blick zu verstehen sein, um Verwirrung und menschliche Fehler während einer Krise zu reduzieren.

2. Wählen Sie Plantyp als Drill starten aus.

   
   Abbildung 3.8: Die Parameter, die zum Erstellen eines Start-Drill-Plans erforderlich sind

Der Drilldown stoppen muss erstellt/ausgeführt werden, nachdem ein erfolgreiches Drilldown starten abgeschlossen wurde. Dieser Plan ist für das Beenden der DB-Systeme verantwortlich, die während der Start-Drill-Ausführung erstellt wurden, und das Bereinigen aller temporären Ressourcen, die zu Testzwecken verwendet wurden.

Aufgabe 4: Vorabprüfungen in Teilsektor 2 ausführen

Sowohl Switchover- als auch Failover-DR-Pläne wurden in der Standbyregion 2 erfolgreich erstellt. Mit diesen Plänen kann OCI Full Stack DR Workloads von Region 1 in Region 2 migrieren. Die folgende Aufgabe umfasst die Ausführung der Vorabprüfungen für Switchover- und Failover-Pläne, um die Bereitschaft sicherzustellen und den Übergangsprozess zu validieren.

Aufgabe 4.1: Vorabprüfungen für den Switchover-Plan starten

Vorabprüfungen für den Switchover-DR-Plan ausführen.

1. Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
2. Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
3. Klicken Sie auf den Switchover-Plannamen.
4. Klicken Sie auf Aktion.
5. Klicken Sie auf Vorabprüfungen ausführen.

Abbildung 4.1: Anzeigen der Ausführung von Vorabprüfungen des Switchover-Plans

Abbildung 4.2: Anzeigen, wie Vorabprüfungen des Switchover-Plans ausgeführt werden

Planen Sie Ausführungsgruppen der Switchover-Vorabprüfungen.
Abbildung 4.3: Abgeschlossene Vorabprüfungen des Switchover-Plans anzeigen

Aufgabe 4.2: Vorabprüfungen für den Failover-Plan starten

Führen Sie die Vorabprüfungen für den Failover-DR-Plan aus.

1. Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
2. Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
3. Klicken Sie auf den Failover-Plannamen.
4. Klicken Sie auf Aktion.
5. Klicken Sie auf Vorabprüfungen ausführen.

Abbildung 4.4: Anzeigen, wie Vorabprüfungen des Failover-Plans ausgeführt werden

Abbildung 4.5: Anzeigen, wie Vorabprüfungen des Failover-Plans ausgeführt werden

Planen Sie Ausführungsgruppen der Switchover-Vorabprüfungen.
Abbildung 4.6: Abgeschlossene Vorabprüfungen des Failover-Plans anzeigen

Aufgabe 5: Switchover-Plan in Region 2 ausführen

Führen Sie den Switchover-DR-Plan aus, um mit dem Übergang der WordPress-Anwendung mit MySQL HeatWave von Region 1 in Region 2 zu beginnen.

1. Stellen Sie sicher, dass der Regionskontext auf {\b Standby Region 2} eingestellt ist.
2. Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
3. Klicken Sie auf den Switchover-Plannamen.
4. Klicken Sie auf Aktion.
5. Klicken Sie auf Plan ausführen.

Abbildung 5.1: So führen Sie den Switchover-Plan aus

Mit dieser Aufgabe wird der Switchover-Plan in Region 2 ausgeführt.

1. Heben Sie die Auswahl von Vorabprüfungen aktivieren auf, da diese bereits in Aufgabe 4 ausgeführt wurden.
2. Klicken Sie auf DR-Plan ausführen.

Abbildung 5.2: So führen Sie den Switchover-Plan aus

Klicken Sie auf DR-Plan ausführen, um
Abbildung 5.3: Anzeigen, wie Sie die Ausführung des Switchover-Plans bestätigen

Überwachen Sie den Switchover-Plan, bis die gesamte Workload vollständig von Region 1 in Region 2 übertragen wurde.

Abbildung 5.4: Die Ausführung der Switchover-Plangruppe wird in Bearbeitung angezeigt.

Die Ausführung des Switchover-Plans wurde erfolgreich abgeschlossen.

Abbildung 5.5: Eine abgeschlossene Switchover-Planausführung wird angezeigt.

Aufgabe 6: DR-Pläne in Region 1 erstellen

Nach dem erfolgreichen Abschluss des Switchovers durch OCI Full Stack DR hat Region 2 jetzt die Rolle der primären Region übernommen, während Region 1 als Standbyregion übernommen wurde.

Befolgen Sie denselben Ansatz wie in Aufgabe 3. Erstellen Sie die Switchover- und Failover-Pläne in der DR-Schutzgruppe für Region 1, die jetzt als Standby-Peerregion dient.

Abbildung 6.1: Screenshot mit erstellten Plänen in Region 1

Abbildung 6.2: Screenshot mit einem Switchover-Plan in Region 1

Abbildung 6.3: Screenshot mit einem Failover-Plan in Region 1

Nächste Schritte

Weitere Informationen finden Sie in der Dokumentation zu OCI Full Stack DR und MySQL HeatWave im Abschnitt Zugehörige Links.

Verwandte Links

• Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery

• MySQL HeatWave

• OCI-Full Stack Disaster Recovery

• HeatWave

• Treten Sie dem Slack-Kanal #full-stack-dr bei

Bestätigungen

• Autor – Antoun Moubarak (Architekt, Büro des CTO – EMEA Technology Engineering)

• Beitragender – Suraj Ramesh (Produktmanager für OCI Full Stack DR)

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Automate Disaster Recovery for MySQL HeatWave with Replication Channels Using OCI Full Stack Disaster Recovery

G42702-02

Copyright ©2025,

Oracle und/oder verbundene Unternehmen.