Oracle Database File System-(DBFS-)Replikation implementieren

Diese Implementierung besteht darin, den Mid-Tier-Inhalt in einen DBFS-Ordner zu kopieren und auf Oracle Data Guard zu vertrauen, um ihn auf der sekundären Site zu replizieren. Die Mid-Tier-Inhalte befinden sich nicht direkt in DBFS, da dies die Middle Tier von der DBFS-Infrastruktur (Datenbank, FUSE-Librarys, Mount Points usw.) abhängig machen würde. Der DBFS-Mount ist nur ein Zwischenspeicherordner, in dem eine Kopie des Inhalts gespeichert wird.

Jede Replikation in Standby umfasst zwei Schritte in diesem Modell: vom Ursprungsordner der Primärdatenbank bis zum Zwischen-DBFS-Mount und dann auf der sekundären Site vom DBFS-Mount zum Zielordner der Standbydatenbank. Die Zwischenkopien werden mit rsync erstellt. Da es sich um eine lokale rsync-Kopie mit geringer Latenz handelt, werden mit diesem Modell einige Probleme vermieden, die bei einem Remote-rsync-Kopiervorgang auftreten.

Hinweis:

Diese Methode wird in Oracle Autonomous Database nicht unterstützt, da DBFS-Verbindungen nicht zulässig sind.

Beschreibung der Abbildung replica-mid-tier-dbfs.png

replica-mid-tier-dbfs-oracle.zip

Die Implementierung des Mid-Tier-Replikats mit DBFS bietet folgende Vorteile:

• Diese Methode nutzt die Robustheit des Oracle Data Guard-Replikats.
• Der echte Mid-Tier-Speicher kann in den sekundären Knoten gemountet bleiben. Es gibt keine zusätzlichen Schritte, um den Speicher bei jedem Switchover- oder Failover-Vorgang im sekundären Speicher anzuhängen oder einzuhängen.

Bei der Implementierung des Mid-Tier-Replikats mit DBFS sind folgende Aspekte zu beachten:

• Für diese Methode ist eine Oracle Database mit Oracle Data Guard erforderlich.
• Die Mid-Tier-Hosts benötigen den Oracle Database-Client, um DBFS zu mounten.
• Die Verwendung von DBFS für die Replikation hat Auswirkungen auf das Setup, den Datenbankspeicher und den Lebenszyklus. Es erfordert eine Installation des Oracle Database-Clients auf den Mid-Tier-Hosts, eine bestimmte Datenbankwartung (um den Tabellenspeicher zu bereinigen, zu komprimieren und zu reduzieren) und ein gutes Verständnis für das Verhalten der DBFS-Mount Points.
• Die DBFS-Verzeichnisse können nur gemountet werden, wenn die Datenbank geöffnet ist. Wenn Oracle Data Guard kein Active Data Guard ist, befindet sich die Standbydatenbank im Mountzustand. Damit Sie auf den DBFS-Mount auf der sekundären Site zugreifen können, müssen Sie die Datenbank in eine Snapshot-Standbydatenbank konvertieren. Wenn Active Data Guard verwendet wird, kann das Dateisystem für Lesevorgänge gemountet werden, und es ist kein Übergang zu einem Snapshot erforderlich.
• Es wird nicht empfohlen, DBFS als allgemeine Lösung zu verwenden, um alle Artefakte (insbesondere Laufzeitdateien) in die Standbydatenbank zu replizieren. Die Verwendung von DBFS zum Replizieren der Binärdateien ist übertrieben. Dieser Ansatz eignet sich jedoch zum Replizieren einiger Artefakte, wie der Konfiguration, wenn andere Methoden wie die Speicherreplikation oder rsync nicht den Systemanforderungen entsprechen.
• Es liegt in der Verantwortung des Benutzers, die benutzerdefinierten Skripte für jede Umgebung zu erstellen und regelmäßig auszuführen.
• Es liegt in der Verantwortung des Benutzers, eine Möglichkeit zur Umkehrung der Replikationsrichtung zu implementieren.

Replikation für Datenbankdateisystem einrichten

Diese Implementierung verwendet die rsync-Technologie und folgt dem Peer-to-Peer-Modell. In diesem Modell erfolgt die Kopie direkt zwischen den Middle Tier-Peer-Hosts. Jeder Knoten verfügt über SSH-Konnektivität zu seinem Peer und verwendet rsync-Befehle über SSH, um die primären Mid-Tier-Dateiartefakte zu replizieren.

Um ein Mid-Tier-Replikat mit DBFS zu implementieren, ist Folgendes erforderlich:

• Eine Oracle Database-Clientinstallation auf den Mid-Tier-Hosts, die den Kopiervorgang sowohl in der primären als auch in der sekundären Datenbank ausführen.
• Ein in der Datenbank erstelltes DBFS-Dateisystem.
• Ein DBFS-Mount auf den Mid-Tier-Hosts, der die Kopien sowohl in der primären als auch in der sekundären Datenbank durchführt. Dadurch wird das DBFS-Dateisystem der Datenbank gemountet. Dieses Dateisystem kann auf mehreren Hosts gemountet werden, da DBFS ein gemeinsam nutzbares Dateisystem ist.
• Skripte, mit denen die Mid-Tier-Dateiartefakte in den DBFS-Mount auf der primären Site kopiert werden.
• Skripte, mit denen die Mid-Tier-Dateiartefakte aus dem DBFS-Mount in die Ordner der sekundären Site kopiert werden. Je nach Implementierung erfordert diese Methode möglicherweise SQL*net-Konnektivität zwischen den Mid-Tier-Hosts und der Remotedatenbank für Datenbankvorgänge wie Rollenkonvertierungen.
• Eine Möglichkeit, die standortspezifischen Informationen zu verwalten, indem diese Informationen entweder aus der Kopie ausgeschlossen oder mit den entsprechenden Informationen nach dem Replikat aktualisiert werden.
• Planen Sie die fortlaufende Ausführung dieser Skripte.
• Ein Mechanismus zum Ändern der Richtung des Replikats nach einem Switchover oder Failover.

Beispiel 1: Oracle WebLogic-Domain mit DBFS replizieren

Hinweis:

Das folgende Beispiel gilt für Oracle WebLogic-Systeme. Sie können es als Referenz verwenden, um andere Ordner des Mid-Tier-Systems über DBFS zu kopieren. In diesem speziellen Beispiel wird jedoch ein Skript verwendet, das den Domainordner des WebLogic-Administrators über DBFS in den sekundären Ordner repliziert.

In diesem Beispiel wird gezeigt, wie Sie den Domainordner des Administrationshosts WebLogic über DBFS replizieren. Der Inhalt, der sich außerhalb des Domainordners befindet, sowie der Inhalt auf anderen Hosts sind in diesem Beispiel nicht enthalten. Der Domainordner befindet sich nicht direkt in DBFS. Der DBFS-Mount ist nur ein Zwischenspeicherordner, in dem eine Kopie des Domainordners gespeichert wird.

Dieses Beispiel enthält ein Skript, um diese Aktionen auszuführen, die regelmäßig auf Primär- und Standbysites ausgeführt werden müssen. Dieses Skript kopiert den Ordner der WebLogic-Administrationsdomain und überspringt einige Elemente wie die Dateien tmp, .lck, .state und tnsnames.ora. Das Verfahren besteht aus:

• Wenn das Skript auf dem WebLogic-Administrationshost der primären Site ausgeführt wird, kopiert das Skript den Domainordner WebLogic in den DBFS-Ordner.
• Die in das DBFS kopierten Dateien, die in der Datenbank gespeichert sind, werden automatisch über Oracle Data Guard an die Standbydatenbank übertragen.
• Wenn das Skript auf dem Administrationshost WebLogic der Sekundärsite ausgeführt wird:
  • Das Skript konvertiert die Standbydatenbank in eine Snapshot-Standbydatenbank.
  • Anschließend wird das DBFS-Dateisystem aus der Standbydatenbank gemountet.
  • Der replizierte Domainordner ist jetzt in diesem DBFS-Ordner verfügbar. Das Skript kopiert es aus dem DBFS-Mount in den echten Domainordner.
  • Schließlich konvertiert das Skript die Standbydatenbank erneut in eine physische Standbydatenbank.
• Im Falle einer Rollenänderung passt das Skript die Ausführung automatisch an die neue Rolle an. Sie sammelt die tatsächliche Rolle der Site, indem sie die Datenbankrolle prüft.

Dieses Skript repliziert nur den Domainordner des Administrationshosts WebLogic. Der Inhalt unter dem Ordner DOMAIN_HOME/config wird automatisch auf alle anderen Knoten kopiert, die Teil der Domain WebLogic sind, wenn die Managed Server gestartet werden. Die Dateien außerhalb dieses Ordners und die Dateien auf anderen Hosts werden nicht repliziert und müssen separat synchronisiert werden.

Verwenden Sie für Anwendungs-Deploymentvorgänge die Deployment-Option Dateien hochladen in der WebLogic-Administrationskonsole. Auf diese Weise werden die bereitgestellten Dateien unter dem Uploadverzeichnis des Administrationsservers ($DOMAIN_HOME/servers/admin_server_name/upload) abgelegt, und das Konfigurationsreplikatskript synchronisiert sie mit der Standbysite.

In diesem Beispiel wird ein weiteres Skript zur Installation des DB-Clients und zur Konfiguration eines DBFS-Mounts auf den Mid-Tier-Hosts bereitgestellt. Das Image ist ein Beispiel für ein Oracle WebLogic Server for OCI-System mit DBFS-Replikation.

Beschreibung der Abbildung wls-dbfs-replication.png

wls-dbfs-replication-oracle.zip

Führen Sie die folgenden Schritte aus, um die DBFS-Methode zum Replizieren der Domain WebLogic zu verwenden:

1. SQL*net-Konnektivität zwischen den Administrationshosts und den Remote-Datenbanken zulassen.
   Oracle empfiehlt die Verwendung von Remote-Peering mit dem dynamischen Routinggateway. Das Skript erfordert diese Konnektivität, um Datenbankvorgänge wie Rollenkonvertierungen auszuführen. Wenn das Skript auf der Site mit der Standbyrolle ausgeführt wird, konvertiert es die Standbydatenbank in eine Snapshot-Standbydatenbank, um den DBFS-Mount zu mounten.
2. Laden Sie die Skripte herunter.
   Dieses Dokument enthält Skripte zur Konfiguration des DBFS-Mounts und zur Automatisierung der Replikation.
   1. Gehen Sie zum Oracle MAA-Repository in GitHub. Weitere Informationen finden Sie im Abschnitt "Weitere Informationen" in diesem Playbook.
   2. Laden Sie alle Skripte im Verzeichnis app_dr_common herunter.
   3. Laden Sie alle Skripte im Verzeichnis wls_mp_dr herunter.
   4. Kopieren Sie sie auf den primären und sekundären Administrationshost in einen Speicherort, der nicht repliziert wird.
   5. Die Skripte rufen einander auf. Kopieren Sie die Skripte beider Verzeichnisse, und legen Sie sie im selben Ordner ab. Stellen Sie sicher, dass der Benutzer oracle über Ausführungsberechtigungen verfügt.
3. Konfigurieren Sie den DBFS-Mount auf primären und sekundären Administrationshosts.

   Hinweis:

   Wenn Sie bereits einen DBFS-Mount haben, können Sie diesen Schritt überspringen. Beispiel: Einige SOA Marketplace-Stacks verfügen über einen gebrauchsfertigen DBFS-Mount.
   Konfigurieren Sie den DBFS-Mount auf den primären und sekundären WebLogic-Administrationshosts. Dazu sind der Datenbankclient und einige Betriebssystempackages auf dem Administrationshost WebLogic erforderlich. Führen Sie in jedem Administrationshost die folgenden Schritte aus:
   1. Laden Sie den DB-Client aus der E-Zustellung herunter, und laden Sie ihn auf den Mid-Tier-Host hoch (noch NICHT installieren). Suchen Sie nach Oracle Database Client, und wählen Sie nur den Datenbankclient aus. Klicken Sie auf Weiter, und wählen Sie die Version des Installationsprogramms aus (nicht das Gold Image).

      Hinweis:

      Stellen Sie sicher, dass Sie die Installationsversion herunterladen, nicht die abbildbasierte Installation. Es wird empfohlen, die neueste Version zu verwenden.
      Beispiel: Laden Sie die Datei 982064-01.zip für Oracle Database Client 19.3.0.0.0 für Linux x86-64 und 1.1 GB herunter, und laden Sie sie auf allen Mid-Tier-Hosts in /u01/install/V982064-01.zip hoch.

      Installieren Sie es noch nicht.

   2. Suchen Sie das Skript dbfs_dr_setup_root.sh unter dem Ordner app_dr_common.
      Dieses Skript führt die Aufgaben aus, um den DBFS-Mount auf dem Host bereit zu stellen. Er installiert den Datenbankclient und die erforderlichen Betriebssystempackages, konfiguriert den DBFS-Benutzer und das DBFS-Schema in der Datenbank, mountet das DBFS-Dateisystem und erstellt eine cron, sodass das DBFS-Dateisystem beim Booten des Hosts gemountet wird.
   3. Ausführen Sie das Skript als root-Benutzer.
      Die Syntax lautet wie folgt:

      ./dbfs_dr_setup_root.sh  local_db_scan_name db_port  local_PDB_service pdb_sys_password path_to_dbclient_installer

      Geben Sie als Eingabeparameter die Verbindungsdaten an, die für die Anmeldung bei der lokalen Datenbank verwendet werden, die von WLS verwendet wird: Geben Sie die Verbindungsdaten der primären PDB an, wenn Sie sie auf dem Administrationshost der primären Site ausführen, und geben Sie die Verbindungsdaten der sekundären PDB an, wenn Sie sie auf dem sekundären Administrationshost ausführen.

      Hinweis:

      Die Standbydatenbank muss sich im Snapshot-Standbymodus befinden, um dieses Skript auf dem sekundären Administrationshost ausführen zu können.
      Im folgenden Beispiel wird der primäre Mid-Tier-Verwaltungshost ausgeführt. Es muss eine einzelne Zeile sein, und Sie müssen die Werte der primären PDB und Ihr Kennwort angeben:

      ./dbfs_dr_setup_root.sh  drdba-scan.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

      Im folgenden Beispiel wird der sekundäre Verwaltungshost der mittleren Netzwerkebene ausgeführt. Es muss eine einzelne Zeile sein, und Sie müssen die Werte der primären PDB und Ihr Kennwort angeben:

      ./dbfs_dr_setup_root.sh  drdbb-scan.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

      Als Ergebnis der Ausführung dieses Skripts erhalten Sie Folgendes:

      Artefakt	Datum	Beschreibung
      Home des Datenbankclients	/u01/app/oracle/client	Das Skript installiert die Datenbankclientsoftware auf dem Host. Außerdem wird yum verwendet, um die erforderlichen Packages zu installieren.
      Datenbankbenutzer	Name: dbfsuser Kennwort: identisch mit sys	Ein Benutzer in der PDB-Datenbank für DBFS.
      DBFS-Tablespace	tbsdbfs	Ein Tablespace in der PDB für den DBFS-Mount.
      DBFS-Ordner	dbfsdir	Der DBFS-Ordner im Tablespace.
      Ein Ordner auf dem Middle Tier-Host	DOMAIN_HOME/dbfs	Er enthält das Wallet, in dem der Benutzer, das Kennwort und andere Artefakte (tnsnames.ora, sqlnet.ora) gespeichert sind, die vom Datenbankclient zum Mounten des DBFS im Host erforderlich sind.
      Skript auf dem Middle Tier-Host	DOMAIN_HOME/dbfs/dbfsMount.sh	Skript zum Mounten des DBFS-Dateisystems auf dem Host. Dieses Skript wird dem Skript cron beim Neustart hinzugefügt und daher beim Neustart des Computers ausgeführt.
      Mount Point auf dem Mid-Tier-Host	/u02/data/dbfs_root	Das DBFS-Dateisystem wird im /u02/data/dbfs_root-Mount Point als Ordner dbfsdir gemountet.

      Sie können das Skript erneut ausführen, erhalten jedoch Warnungen, da einige Elemente bereits erstellt wurden (DB-Benutzer, Tablespace usw.). Sie können diese Meldungen ignorieren.

   4. Prüfen Sie, ob der DBFS-Mount auf dem Middle Tier-Administrationshost vorhanden ist.

      [root@ prefix-wls-1]# df -h | grep dbfs
      dbfs-@PDB1:/     32G  248K   32G   1% /u02/data/dbfs_root
      [root@ prefix-wls-1]# ls /u02/data/dbfs_root
      dbfsdir

      Dieses DBFS-Dateisystem wird als Assistenzdateisystem verwendet, um eine Kopie der Domainkonfiguration der primären Site zu speichern.
4. Bereiten Sie das Replikatskript vor.
   Dieses Dokument enthält ein Referenzskript für diese Implementierung, das Skript config_replica.sh.
   1. Öffnen Sie im primären Oracle WebLogic-Administrationshost das Skript config_replica.sh. Bearbeiten Sie die anpassbaren Parameterabschnitte.
      Stellen Sie sicher, dass Sie die entsprechenden Variablen für die Primärdatenbank angeben. Verwenden Sie in der Eigenschaft DR_METHOD DBFS.
   2. Führen Sie denselben Vorgang auf dem sekundären Oracle WebLogic-Administrationshost aus. Stellen Sie sicher, dass Sie die entsprechenden Variablen für die Sekundärkomponente angeben.
5. Führen Sie das Replikationsskript aus.
   1. Führen Sie als Benutzer oracle das Skript config_replica.sh im primären Oracle WebLogic-Administrationshost aus.
      Das Skript prüft die aktuelle Siterolle und kopiert die Domainkonfiguration aus der primären Oracle WebLogic Server-Domain in den DBFS-Mount.
   2. Überwachen Sie die Ausführung, und achten Sie auf Fehler.
   3. Führen Sie nach Abschluss das Skript config_replica.sh auf dem Oracle WebLogic Administration Server-Host der sekundären Site aus.
      Stellen Sie sicher, dass Sie die entsprechenden Werte in den angepassten Parametern verwenden. Das Skript überprüft die Datenbankrolle. Da es sich um die Standbydatenbank handelt, wird die Domainkonfiguration aus dem sekundären Staging-Dateisystem in die sekundäre Oracle WebLogic Server-Domain kopiert.

   Hinweis:

   Dieses Skript muss immer sowohl in der Primär- als auch in der Standbydatenbank ausgeführt werden, um eine vollständige Replikation durchzuführen: zuerst in der Primärdatenbank, um die Domain in den DBFS-Ordner zu kopieren, und dann in der Standbydatenbank, um die Domain aus dem DBFS in den Domainordner zu kopieren. Die Häufigkeit hängt davon ab, wie oft die Konfigurationsänderungen in der Oracle WebLogic Server-Domain ausgeführt werden.

Replikation für Datenbankdateisystem validieren

Bei einem Switchover- oder Failover-Vorgang müssen die replizierten Informationen in der Standby Site verfügbar und verwendbar sein, bevor die Prozesse gestartet werden. Dies ist auch erforderlich, wenn Sie das sekundäre System validieren (durch Öffnen der Standbydatenbank im Snapshot-Modus).

In dieser Implementierung ist der Speicher immer in der Standbydatenbank verfügbar. Sie müssen kein Volume anhängen oder mounten. Die einzige Maßnahme, die Sie benötigen, ist sicherzustellen, dass sie die neueste Version des Inhalts enthält.

Um den replizierten Inhalt im Standby-Modus zu verwenden, gehen Sie wie folgt vor:

1. Replikation ausführen
   Führen Sie die Replikatskripte aus, um den neuesten Inhalt im sekundären System verfügbar zu machen.
2. Deaktivieren Sie geplante Replikationen.
   Wenn das letzte Replikat abgeschlossen ist, deaktivieren Sie jedes Replikatskript. Andernfalls kann es die Switchover-, Failover- oder Validierungsprozedur beeinträchtigen. Sie aktivieren es nach dem Vorgang erneut in die entsprechende Richtung.

Laufende Replikation für Datenbankdateisystem ausführen

Führen Sie das Replikationsskript regelmäßig aus, um die sekundäre Domain mit der primären Domain synchron zu halten.

Befolgen Sie diese Empfehlungen, wenn Sie rsync von den Mid-Tier-Hosts verwenden:

• Verwenden Sie das Betriebssystem crontab oder ein anderes Planungstool, um die Replikation zu planen. Sie muss zulassen, dass die Skripte die Replikation abschließen. Andernfalls können sich die nachfolgenden Jobs überschneiden.
• Halten Sie die Mid-Tier-Prozesse in der Standby Site gestoppt. Wenn die Server in der Standby Site hochgefahren sind, während die Änderungen repliziert werden, werden die Änderungen beim nächsten Start wirksam. Starten Sie sie nur, wenn Sie die Standby Site validieren oder während des Switchover- oder Failover-Vorgangs.
• Verwalten Sie die spezifischen Informationen für jede Site, und halten Sie sie auf dem neuesten Stand. Beispiel: Überspringen Sie die tnsnames.ora aus der Kopie, damit jedes System seine Konnektivitätsdetails aufweist. Wenn Sie eine Änderung in der tnsnames.ora in der Primärdatenbank vornehmen (z.B. ein neuer Alias hinzufügen), aktualisieren Sie die tnsnames.ora in der Sekundärdatenbank manuell entsprechend.
• Nach einem Switchover oder Failover reverse die Replikatrichtung. Dies hängt von der konkreten Umsetzung ab. Die Skripte können eine dynamische Prüfung verwenden, um festzustellen, wer die aktive Site ist, oder Sie können nach einem Switchover oder Failover eine manuelle Änderung vornehmen (z.B. das Deaktivieren und Aktivieren der entsprechenden Skripte). Im angegebenen Beispiel passt das Skript config_replica.sh die Ausführung automatisch an die tatsächliche Rolle der Site an, indem die Rolle der lokalen Datenbank geprüft wird.