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äre 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 WebLogic Server-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 JMS-Nachrichten in der Datenbank ausstehen, wenn sie in einen Snapshot konvertiert werden, verarbeiten die Server der Standbysite sie beim Starten. Stellen Sie sicher, dass bei der Konvertierung in die Snapshot-Standbydatenbank keine ausstehenden Aktionen in der Primärdatenbank vorhanden sind.

Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker auf dem 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.
Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme auf der sekundären Site.
Starten Sie den Administrationsserver auf der sekundären Site.
Starten Sie die sekundären Managed Server in der sekundären Site.
Verwenden Sie die WebLogic-Konsole oder -Skripte, um die sekundären Managed Server zu starten.
Validieren Sie die sekundäre Site.

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 WebLogic-Serveranwendungen 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 zur Auflösung in die Frontend-IP-Adresse der sekundären Site festlegen 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 müssen möglicherweise ihren lokalen DNS-Cache zurücksetzen, 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:
Es kann einige Zeit dauern, die sekundäre Site zu validieren.
Stoppen Sie die Managed Server und Admin-Server in der sekundären Site.
Verwenden Sie die sekundäre WebLogic-Konsole, um die Managed Server und den Admin-Server in der sekundären Site herunterzufahren.
Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker auf dem primären Datenbankhost, und konvertieren Sie die sekundäre in die physische Standbydatenbank 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.
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.

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 WebLogic Server-Hybrid-DR-Konfiguration ausführen, propagieren Sie alle ausstehenden Konfigurationsänderungen. Stellen Sie sicher, dass keine replizierten Änderungen an der sekundären Site ausstehen.

Deaktivieren Sie eine geplante Replikation, während das Switchover ausgeführt wird, da dies möglicherweise nicht erfolgreich verläuft und den Switchover-Vorgang selbst beeinträchtigt.
Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
Stoppen Sie die Server in der primären Site.
Verwenden Sie die Administrationsserverkonsole WebLogic oder Skripte, um die WebLogic-Server in 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 von der primären Konfiguration außer Kraft gesetzt wird. Wenn der Admin-Server während dieses Vorgangs hochgefahren ist, wird er mit einer veralteten Konfiguration ausgeführt.
Wechseln Sie zum Frontend-DNS-Namen.

Führen Sie den erforderlichen DNS-Push in den 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 in 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 (Beispiel: 20 Min.), dauert die DNS-Änderung diese Zeit, bis sie in den Clients wirksam wird. Wenn Sie niedrigere TTL-Werte verwenden, wird dies beschleunigt. Dies kann jedoch zu einem Overhead führen, da Clients das DNS häufiger erreichen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, den TTL-Wert vorübergehend (z.B. 1 Min.) vor der Änderung im DNS auf einen niedrigen Wert zu setzen. Führen Sie dann die Änderung aus. Sobald die Switchover-Prozedur abgeschlossen ist, setzen Sie die TTL wieder auf ihren ursprünglichen Wert zurück.
Verwenden Sie als oracle-Benutzer den Oracle Data Guard-Broker auf dem Primärdatenbankhost, um den 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
```
Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
Starten Sie den Admin-Server auf der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
Durch das Starten des Admin-Servers werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
Starten Sie die sekundären Managed Server in der sekundären Site (neue primäre Site).
Verwenden Sie die WebLogic-Konsole oder -Skripte, um die sekundären Managed Server zu starten.