Konfiguration überprüfen

Nachdem das DR-Setup abgeschlossen ist, prüfen Sie sofort, ob das Setup korrekt ist, indem Sie einen vollständigen Switchover ausführen oder den sekundären Standort zur Validierung öffnen. Das Öffnen der sekundären Site zur Validierung wirkt sich nicht auf das in der primären Site ausgeführte System aus.

Sekundär zur Validierung öffnen

Sie können die Standbysite validieren, ohne einen vollständigen Switchover auszuführen, indem Sie die Standbydatenbank in Snapshot Standby konvertieren. Dadurch können die sekundären SOA-Server auf der Standbysite gestartet und das sekundäre System geprüft werden. Alle Änderungen, die in der Standbydatenbank vorgenommen werden, während sie sich im Snapshot Standby-Modus befindet, werden verworfen, sobald sie wieder in die physische Standbydatenbank konvertiert werden. Primäre Daten sind von Validierungen der sekundären Site nicht betroffen.

Hinweis:

Dieser Vorgang muss mit Vorsicht ausgeführt werden: Wenn bei der Konvertierung in einen Snapshot ausstehende Nachrichten oder Composites in der Datenbank vorhanden sind, verarbeiten die SOA-Server der Standbysite diese beim Start. Prüfen Sie, ob keine ausstehenden Aktionen in der Primärdatenbank bei der Konvertierung in die Snapshot Standby-Datenbank vorhanden sind. Andernfalls entfernen Sie Datensätze aus SOA-Laufzeittabellen in der Standbydatenbank, nachdem sie in die Snapshot-Standbydatenbank konvertiert wurde, und bevor Sie die SOA-Server der sekundären Site starten. Die Schritte zum Validieren der Standby Site ohne Switchover finden Sie unter Datensätze aus Laufzeittabellen entfernen, ohne die Tabellen zu löschen.

1. Verwenden Sie als oracle-Benutzer Oracle Data Guard-Broker im primären DB-Host, und konvertieren Sie die sekundäre Datenbank in eine Snapshot Standby-Datenbank.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> convert database secondary_db_unqname to snapshot standby
   

   Prüfen Sie mit dem Befehl show configuration, ob die Konvertierung korrekt ausgeführt wurde.
2. Stellen Sie sicher, dass keine ausstehenden Aktionen in der sekundären Umgebung vorhanden sind.
   Wenn bei der Konvertierung der Standbydatenbank in einen Snapshot ausstehende Aktionen (Transaktionen, Nachrichten) in der primären DB vorhanden sind, versuchen die sekundären SOA-Server, diese zu verarbeiten, wenn sie start.You das SOA-Kürzungsskript verwenden können, um die Datensätze aus den SOA-Laufzeittabellen in der sekundären Datenbank zu entfernen, um die Laufzeitdaten zu bereinigen, bevor die sekundären Server gestartet werden. Führen Sie diese Aktion mit VORSICHT aus. Schneiden Sie keine Tabellen in der Primärdatenbank ab. Siehe Datensätze aus Laufzeittabellen entfernen, ohne die Tabellen zu löschen.
3. Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme auf der sekundären Site.
4. Starten Sie den Administrationsserver auf der sekundären Site.
5. Starten Sie die sekundären Managed Server auf der sekundären Site.
   Verwenden Sie die Konsole oder die Skripte WebLogic, um die sekundären Managed Server zu starten.
6. Sekundäre Site validieren.

   Da dies kein Switchover ist und die primäre Site noch aktiv ist, wird der virtuelle Frontend-Name in die Load-Balancer-IP-Adresse der primären Site aufgelöst, sodass jeder Browserzugriff standardmäßig auf die aktive primäre Site umgeleitet wird.

   Um direkt auf die SOA-Services der sekundären Site zuzugreifen, müssen Sie die Datei /etc/hosts in einem kontrollierten Client (z.B. einem Laptop) aktualisieren, den virtuellen Frontend-Namen auf die Frontend-IP-Adresse der sekundären Site setzen und eine Validierung von diesem Client ausführen.

   Hinweis:

   Stellen Sie sicher, dass der für Validierungen verwendete Client nicht über einen HTTP-Proxy auf das System zugreift, da der HTTP-Proxy den virtuellen Frontend-Namen weiterhin mit der IP-Adresse des Load Balancers der primären Site auflösen kann, unabhängig davon, welcher Name im /etc/hosts des Clients enthalten ist.

   Nicht-Linux-Clients erfordern möglicherweise eine Zurücksetzung ihres lokalen DNS-Caches, bevor ein Browser die IP-Adresse mit dem benutzerdefinierten Hostdateieintrag auflöst.

   Nachdem die sekundäre Site validiert wurde, gehen Sie zum nächsten Schritt, um sie auf die Standbyrolle zurückzusetzen.

   Hinweis:

   Die Validierung der sekundären Site kann einige Zeit in Anspruch nehmen.
7. Stoppen Sie die Managed Server und Administration Server auf der sekundären Site.
   Verwenden Sie die sekundäre WebLogic-Konsole, um die Managed Server und den Admin-Server auf der sekundären Site herunterzufahren.
8. Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker im primären Datenbankhost, und konvertieren Sie die sekundäre in die physische Standby-Datenbank erneut.
   Sie benötigen Ihr Systemkennwort und den eindeutigen Namen der Primärdatenbank.

   [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
       DGMGRL> convert database secondary_db_unqname to physical standby

   Verwenden Sie show configuration, um die Konvertierung zu prüfen.
9. Stellen Sie alle aktualisierten /etc/hosts-Dateien wieder her.
   Wenn Sie /etc/hosts-Dateien in einem Client so aktualisiert haben, dass sie auf die sekundäre Site für Validierungen verweisen, setzen Sie den Vorgang zurück, sodass der virtuelle Frontend-Name erneut auf die primäre Frontend-IP-Adresse verweist.

Hinweis:

ORA-01403: Keine Daten gefunden ORA-06512 Fehler

Beim Validieren der sekundären Site wie hier beschrieben (ohne ein vollständiges Switchover auszuführen, d.h. nur das Öffnen der Standby-Datenbank im Snapshot Standby-Modus) "ORA-01403: In den Logs der Standby-SOA-Server können keine ORA-06512-Fehler gefunden werden. Diese Fehler beziehen sich auf den SOA-Job zum automatischen Löschen. Diese Fehler treten auf, weil Jobs in der Datenbank möglicherweise DB-Rollenabhängigkeiten aufweisen (sie sind nur dann aktiviert, wenn sich die Datenbank in der primären Rolle befindet). Dies ist ein erwartetes und gewünschtes Verhalten, das verhindert, dass Jobs zweimal ausgeführt werden (einmal in der primären Datenbank und einmal in der Standby-Datenbank). Der SOA-Job zum automatischen Löschen ist mit der primären Rolle definiert. Er wird daher nicht in der Ansicht DBA_SCHEDULER_JOBS angezeigt, wenn sich die Datenbank im Snapshot Standby-Modus befindet. Die für jeden Job definierte database_role kann in der Ansicht DBA_SCHEDULER_JOB_ROLE angezeigt werden. Zusammenfassend lässt sich sagen, dass diese Fehler ignoriert werden können, solange sie im Standby-System angezeigt werden. Der Scheduler-Job für das automatische Löschen von SOA wird in der Datenbank ausgeführt, wenn die Instanz ihre Rolle in PRIMARY ändert.

Switchover ausführen

Ein Switchover ist ein geplanter Vorgang, bei dem ein Administrator die Rollen der beiden Sites zurücksetzt. Nach einem Switchover wird das primäre System zum sekundären und das sekundäre System zum primären System. Bei einem Switchover kommt es zu Ausfallzeiten in der primären Site.

Bevor Sie einen Switchover in einer SOA-Hybrid-DR-Konfiguration ausführen, propagieren Sie alle ausstehenden Konfigurationsänderungen. Stellen Sie sicher, dass keine replizierten Änderungen an der sekundären Site ausstehen.

1. Deaktivieren Sie die geplante Replikation während des Switchovers, da sie möglicherweise ausfällt und den Switchover-Vorgang selbst beeinträchtigt.
2. Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
3. Stoppen Sie die Server auf der primären Site.
   Verwenden Sie die WebLogic Administration Server-Konsole oder die Skripte, um die WebLogic-Server auf der primären Site zu stoppen.

   Hinweis:

   Der Admin-Server in der primären Site kann während des Switchovers hochgefahren bleiben. Es wird jedoch empfohlen, sie zu stoppen, wenn sich die Site in der Standbyrolle befindet, da erwartet wird, dass die Domainkonfiguration in der Standby Site während des Lebenszyklus durch die primäre Konfiguration außer Kraft gesetzt wird. Wenn der Admin-Server hochgefahren ist, wird er mit einer veralteten Konfiguration ausgeführt.
4. Wechseln Sie zum Frontend-DNS-Namen.

   Führen Sie den erforderlichen DNS-Push in dem DNS-Server aus, der die vom System verwendeten Namen hostet, oder ändern Sie die Dateihostauflösung in Clients, um den virtuellen Frontend-Namen des Systems auf die öffentliche IP zu verweisen, die vom Load Balancer auf der sekundären Site verwendet wird.

   Für Szenarios, in denen DNS für die externe Frontend-Auflösung verwendet wird (wie OCI-DNS oder kommerzielles DNS), können Sie die Änderung mit einer API per Push übertragen. Um ein Beispiel anzuzeigen, in dem diese Änderung in einem OCI-DNS übertragen wird, gehen Sie zu GitHub. Beispielskripte.

   Beachten Sie, dass sich der TTL-Wert des DNS-Eintrags auf das RTO des Switchovers auswirkt: Wenn der TTL-Wert hoch ist (z.B. 20 Minuten), nimmt die DNS-Änderung diese Zeit in den Clients in Anspruch. Wenn Sie niedrigere TTL-Werte verwenden, ist dies schneller. Dies kann jedoch zu einem Overhead führen, da Clients das DNS häufiger treffen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, die TTL vorübergehend (z.B. 1 Min.) auf einen niedrigen Wert zu setzen, bevor die DNS-Änderung erfolgt. Führen Sie dann die Änderung aus. Sobald die Switchover-Prozedur abgeschlossen ist, setzen Sie die TTL wieder auf den ursprünglichen Wert zurück.

5. Verwenden Sie als oracle-Benutzer Oracle Data Guard-Broker im primären Datenbankhost, um das Datenbank-Switchover auszuführen.
   Sie benötigen Ihr Systemkennwort und den eindeutigen Namen der Primärdatenbank.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to secondary_db_unqname

6. Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
7. Starten Sie den Admin-Server in der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
   Wenn Sie den Admin-Server starten, werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
8. Starten Sie die sekundären Managed Server auf der sekundären Site (neue primäre Site).
   Verwenden Sie die Konsole oder die Skripte WebLogic, um die sekundären Managed Server zu starten.