24 オンプレミスMAA Platinum: Active Data Guardと統合されたOracle GoldenGate Microservices Architecture

Oracle GoldenGate MicroservicesとOracle Data Guardを組み合せて統合することで、すべての計画停止および計画外停止でゼロまたはほぼゼロの停止時間を達成するMAA Platinumサービス・レベル構成を実現できます。

これらの構成ベスト・プラクティスに従って、Data Guardスタンバイで保護されているデータベースを使用したOracle GoldenGate Microservicesレプリケーションが、Data Guard保護モードの構成(最大パフォーマンス、最大可用性または最大保護)に関係なく、Oracle Data Guardロール・トランジションに従って透過的かつシームレスに動作するようにします。

次の内容について説明します。

• 前提条件
• タスク1: Oracle GoldenGate用のスタンバイ・データベースの構成
• タスク2: プライマリ・データベース・サービスの変更
• タスク3: スタンバイ・データベース・サービスの作成
• タスク4: スタンバイ・クラスタ・ノードでのDBFSの構成
• タスク5: Oracle GoldenGateソフトウェアのインストール
• タスク6: Oracle GoldenGateデプロイメント・ディレクトリの作成
• タスク7: スタンバイNGINXリバース・プロキシの構成
• タスク8: Oracle Clusterwareの構成
• タスク9: Oracle GoldenGateデータベース接続用のOracle Net TNS別名の作成
• タスク10: Oracle GoldenGateプロセスの構成
• 分散パス・ターゲット変更スクリプトの例

前提条件

オンプレミスMAA Platinumアーキテクチャ構成のタスクを実行する前に、必ず次の前提条件を満たしてください。

• オンプレミスのMAA Platinumの前提条件であるため、「オンプレミス: Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」の説明に従ってOracle GoldenGateを構成します。

• データベース・ファイル・システム(DBFS)は、Data Guardとの統合時に、重要なOracle GoldenGateファイルのために必要です。

• 続行する前に、Oracle Data Guardスタンバイ・データベースも構成済で動作している必要があります。

次に、MAA Platinum構成のベースとなるソフトウェア要件を示します。

• Oracle Grid Infrastructure 19c以降

  Oracle Grid Infrastructureは、ビジネスクリティカルなアプリケーション高可用性を管理するために必要なコンポーネントを提供します。Oracle Clusterware (Oracle Grid Infrastructureのコンポーネント)ネットワーク、データベースおよびOracle GoldenGateリソースを使用すると、障害発生時の可用性を管理できます。

• Oracle Grid Infrastructure Agentバージョン10.2以降

  Oracle Grid Infrastructure Agentは、Oracle Grid Infrastructureコンポーネントを活用して、Oracle GoldenGateとその依存リソース(データベース、ネットワーク、ファイル・システムなど)との統合を提供します。また、エージェントはOracle GoldenGateとOracle Data Guardを統合します。これにより、Oracle GoldenGateはロール・トランジション後に、新しいプライマリ・データベースで再起動されます。

• Oracle Database 19c以上

  Oracle GoldenGateを使用する場合の推奨されるOracle Databaseパッチをすべて示すリストは、My Oracle Supportのドキュメント2193391.1を参照してください。

• Oracle GoldenGate Microservicesバージョン21c以降

  Oracle GoldenGate 21cでは統合ビルド・サポートが導入されているため、単一のソフトウェア・インストールで、レプリケートされたデータの取得と複数の主要なOracle Databaseバージョン(11gリリース2から21c)への適用がサポートされます。これが可能になるのは、Oracle GoldenGateインストールに必要なOracle Databaseクライアント・ライブラリが含まれており、別途データベースORACLE_HOMEをインストールする必要がないためです。

• 重要なOracle GoldenGateファイルを保護およびレプリケートするOracle DBFS

  Oracle Database File System (DBFS)は、MAAによって検証され、Oracle Data GuardおよびOracle GoldenGate構成に推奨される、唯一のファイル・システムです。これは、チェックポイント・ファイルや証跡ファイルなどの必要なOracle GoldenGateファイルの格納場所を、Oracle Data Guardで保護されている同じデータベース内に置くことができ、Oracle GoldenGateファイルとデータベース間の一貫性をシームレスに確保できるためです。

前提条件を満たしている場合は、以降のタスクで構成のベスト・プラクティスに従います。これらのタスクは、Oracle GoldenGate MicroservicesとOracle Data Guardをシームレスに統合するために実行する必要があります。これにより、GoldenGateが、Data Guardロール・トランジションの後に引き続き実行されるようになります。

タスク1: Oracle GoldenGate用のスタンバイ・データベースの構成

スタンバイ・データベースの初期化パラメータは、プライマリ・データベースの初期化パラメータと一致している必要があります。

詳細は、「タスク1: Oracle GoldenGate用のOracleデータベースの構成」を参照してください。これには次のパラメータが含まれます。

• ENABLE_GOLDENGATE_REPLICATION=TRUE

• Oracle GoldenGateソース・データベースの場合は、FORCE LOGGINGモードを有効にし、最小サプリメンタル・ロギングを有効にします。

• GoldenGateソース・データベースの場合や統合Replicat (パラレルまたは非パラレル)を実行している場合は、STREAMS_POOL_SIZEを構成します。

タスク2: プライマリ・データベース・サービスの変更

プライマリ・データベース・サーバーで、Oracle RAC構成での元のOracle GoldenGateの一部として作成された既存のデータベース・サービスを変更します。

サービス・ロールをPRIMARYに設定して、ロール・トランジション後にデータベースがData Guardプライマリ・データベース・ロールになったときのみこのサービスが起動されるようにします。

oracleユーザーとして、次のコマンドを使用してこのサービスを変更します。

$ srvctl modify service -db dbName -service service_name
 -role PRIMARY

データベースがマルチテナント環境の一部である場合は、必ずマルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)の両方のサービスを変更してください。

タスク3: スタンバイ・データベース・サービスの作成

スタンバイ・クラスタでは、スタンバイ・データベースにデータベース・サービスが必要です。これにより、そのデータベースがプライマリ・ロールでオープンされたときにOracle Grid Infrastructure AgentによってOracle GoldenGateデプロイメントが自動的に起動されるようになります。

ソース・データベースがマルチテナント環境にある場合は、ルート・コンテナ・データベース(CDB)とレプリケートされるスキーマを含むプラガブル・データベース(PDB)に、個別のサービスが必要です。マルチテナント環境のターゲット・データベースの場合は、PDBに単一のサービスが必要です。

プライマリ・クラスタでサービスを作成したのと同じ方法で、oracleユーザーとして次のコマンドを使用してサービスを作成します。

$ srvctl add service -db dbName -service service_name
 -preferred instance_1 -available instance_2, instance_3 etc.
 -pdb pdbName -role PRIMARY

プライマリ・クラスタで指定したのと同じサービス名を使用することをお薦めします。このサービスは、–preferredオプションを使用してシングルトン・サービスとして作成する必要があります。これは、このサービスが実行されているクラスタ・ノードでアプリケーション仮想IPアドレス(VIP)、DBFSおよびOracle GoldenGateが実行されるためです。

データベースがマルチテナント環境にない場合、またはデータベースがOracle GoldenGateのターゲット・データベースである場合は、-pdbパラメータを省略します。

タスク4: スタンバイ・クラスタ・ノードでのDBFSの構成

Oracle Data GuardでOracle GoldenGateを構成する場合、お薦めするソリューションはDatabaseファイル・システム(DBFS)のみです。

データベース内のDBFSユーザー、表領域およびファイル・システムは、「タスク4: Oracle RACでのファイル・システムの設定」の説明に従って、以前にプライマリ・データベース内に作成してあります。

残りの構成ステップは、Oracle GoldenGateが実行される可能性があるスタンバイ・クラスタのすべてのノードで必要です。

1. My Oracle Supportのドキュメント869822.1の手順に従って、必要なFUSEライブラリをインストールします(まだインストールされていない場合)。
2. プライマリ・クラスタで作成したのと同じように、IPCプロトコルを使用してtnsnames.oraのOracle Net接続別名を作成します。

   dbfs =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = IPC)(KEY=LISTENER))
         (CONNECT_DATA =
           (SERVICE_NAME = NAME)
          )
       )

3. プライマリ・クラスタで使用されているのと同一の、DBFSのマウントポイントを作成します。

   Oracle GoldenGateデプロイメントの物理的な場所はデプロイメント構成ファイルに含まれているため、このマウント・ポイントが同じであることが重要です。

   たとえば:

   # mkdir /mnt/dbfs

4. mount-dbfs.confファイルとmount-dbfs.shファイルをプライマリ・クラスタからスタンバイ・クラスタ・ノードにコピーします。

   これらをプライマリ・クラスタと同じディレクトリに配置することをお薦めします。

5. 次のコマンド例を使用して、DBFSリソースをOracle Clusterwareに登録します。

   Oracle Multitenantを使用している場合は、必ず、プライマリ・データベースで作成したのと同一の、DBFSリポジトリを含むPDBに、このサービス名を使用してください。

   DBNAME=dbName
   DEPNAME=ora.$DBNAME.oggserv_pdb.svc
   
   crsctl add resource $RESNAME \
     -type cluster_resource \
     -attr "ACTION_SCRIPT=$ACTION_SCRIPT, \
            CHECK_INTERVAL=30,RESTART_ATTEMPTS=10, \
            START_DEPENDENCIES='hard($DEPNAME)pullup($DEPNAME)',\
            STOP_DEPENDENCIES='hard($DEPNAME)',\
            SCRIPT_TIMEOUT=300"

タスク5: Oracle GoldenGateソフトウェアのインストール

Oracle GoldenGateソフトウェアを、Oracle GoldenGate構成の一部となるスタンバイ・クラスタ内のすべてのノードでローカルにインストールします。

インストール・ディレクトリがすべてのノードで同一であり、プライマリ・クラスタのインストール・ディレクトリと一致していることを確認してください。

次の場所で、Oracle GoldenGate 21cソフトウェアまたはそれ以降のバージョンをダウンロードします。

http://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html

タスク6: Oracle GoldenGateデプロイメント・ディレクトリの作成

Oracle GoldenGateサービス・マネージャおよびデプロイメントは、前提条件で必要となるため、プライマリ・クラスタにすでに作成されていますが、特定のディレクトリおよびシンボリック・リンクはスタンバイ・クラスタ・ノードで構成する必要があります。

これらのディレクトリおよびシンボリック・リンクは、「オンプレミス: Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」の一部として実行したタスクで、プライマリ・クラスタ上に作成してあります。

今度は、次のように、スタンバイ・クラスタにあるすべてのOracle RACノードに次のディレクトリおよびシンボリック・リンクを作成します。

1. プライマリ・クラスタ上に複数のGoldenGateサービス・マネージャが構成されており、それぞれ固有のデプロイメントがあり、XAGに個別に登録されている場合、それらは別々のOGG_HOMEソフトウェア・インストール・ディレクトリに属している必要があります。

   プライマリ・クラスタ上で構成されているOGG_HOMEディレクトリのディレクトリおよびシンボリック・リンクは、スタンバイ・クラスタ上と同じである必要があります。

2. パフォーマンス・メトリック・サーバーを有効にしてGoldenGateデプロイメントを作成した場合は、スタンバイOracle RACノードにメトリック・データストアのホーム・ディレクトリを作成する必要があります。

   たとえば、次のように、プライマリ・クラスタ・ノードにあるデータストア・ディレクトリを特定します。

   $ grep RepoDatastorePath <deployment directory>/var/log/pmsrvr.log|uniq
   
   "RepoDatastorePath": "",
    "RepoDatastorePath": "/u01/oracle/goldengate/datastores/ggnorth",

   その後、次のように、すべてのスタンバイ・クラスタ・ノードにそのディレクトリを作成します。

   $ mkdir -p /u01/oracle/goldengate/datastores/ggnorth

3. データベース・リリースがOracle Database 21c (21.3)より前の場合は、プライマリ・クラスタ上に作成されたシンボリック・リンクと一致するように、Oracle GoldenGateデプロイメントの一時ディレクトリのローカル・ストレージを作成します。

   たとえば、プライマリ・クラスタ上に次がある場合は、

   $ ls –lrt DBFS_GoldenGate_deployment_home_directory/var/temp
   
   lrwxrwxrwx  1 oracle oinstall 32 Aug 31 12:27 temp
    -> /u01/oracle/goldengate/deployments/ggnorth/temp

   次のように、スタンバイ・クラスタ・ノードにそれと同じディレクトリを作成します。

   $ mkdir –p /u01/oracle/goldengate/deployments/ggnorth/temp

タスク7: スタンバイNGINXリバース・プロキシの構成

スタンバイNGINXリバース・プロキシを構成するには、次のステップを実行します。

1. NGINXリバース・プロキシをインストールします。

   NGINXリバース・プロキシがまだインストールされていない場合は、https://nginx.org/en/linux_packages.htmlのインストール手順に従います。

   rootユーザーとして、Oracle GoldenGateデプロイメントのNGINX構成ファイルをプライマリ・クラスタ・ノードから単一のスタンバイ・ノード・ディレクトリ/etc/NGINX/conf.dにコピーします。

   たとえば:

   [root@dc2north01]# scp dc1north01:/etc/nginx/conf.d/ogg_north.conf
    /etc/nginx/conf.d

   スタンバイ・クラスタでは、プライマリ・クラスタとは異なるVIP名/アドレスが使用されるため、別のCA署名付き証明書が必要になります。続行する前に、システム管理者に連絡して、会社の標準に従ってサーバー証明書を作成または取得してください。VIPとサービス・マネージャのペアごとに、個別の証明書が必要です。

2. NGINXのサーバー証明書をインストールします。

   ファイル権限400 (-r--------)があるrootが所有する/etc/nginx/sslディレクトリにサーバーCA証明書およびキー・ファイルをインストールします。

   # mkdir /etc/nginx/ssl
   # chmod 400 /etc/nginx/ssl

   プライマリ・クラスタからコピーしたリバース・プロキシ構成ファイルごとに、次の例を使用して証明書およびキー・ファイルの正しいファイル名を設定します。

   ssl_certificate /etc/nginx/ssl/gg-stby-vip1.pem;
   ssl_certificate_key /etc/nginx/ssl/gg-stby-vip1.key;

   CA署名付き証明書を使用する場合、ssl_certificate NGINXパラメータで指定した証明書は、1つのファイルにルート、中間およびCA署名付き証明書が含まれたものである必要があります。この順序は非常に重要です。順序が異なると、NGINXは起動に失敗し、エラー・メッセージが表示されます

   (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)

   ルート証明書と中間証明書は、CA署名付き証明書プロバイダからダウンロードできます。

   単一ファイルは次のコマンド例を使用して生成できます。

   # cat CA_signed_cert.crt intermediate.crt root.crt
    > gg-stby-vip1.pem

   ssl_certificate_keyファイルは、CA署名付き証明書をリクエストする際に必要になる証明書署名リクエスト(CSR)の作成時に生成されるキー・ファイルです。

   プライマリ・クラスタからコピーしたリバース・プロキシ構成ファイル内のserver_nameパラメータを変更して、正しいVIP名に設定します。たとえば:

   変更前:

   server_name dc1north-vip1.example.com;

   変更後:

   server_name dc2north-vip1.example.com;

3. NGINXを検証し再起動します。

   VIPはプライマリ・データベース・サービスが実行されるまでスタンバイ・システムで実行されないため、/etc/sysctl.confファイル内で設定する必要があるパラメータがあります。

   1. rootユーザーとして、/etc/sysctl.confに次の変更を加えます。

      # vi /etc/sysctl.conf

   2. 次のパラメータを追加します。

      # allow processes to bind to the non-local address
      
      net.ipv4.ip_nonlocal_bind = 1

   3. 変更した構成を再ロードします。

      # sysctl -p /etc/sysctl.conf

   4. NGINX構成ファイルを検証して構成内のエラーを検出します。ファイル内にエラーがある場合は、次のコマンドでそれらが報告されます。

      # nginx -t
      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
      nginx: configuration file /etc/nginx/nginxconf test is successful

   5. 新しい構成でNGINXを再起動します。

      # systemctl restart nginx

   NGINX構成が完了したら、その構成ファイルおよび証明書を、他のスタンバイ・クラスタ・ノード上の一致するディレクトリにコピーします。

4. NGINX Clusterwareリソースを作成します。

   Oracle Clusterwareは、NGINXリバース・プロキシの起動を制御して、GoldenGateデプロイメントの起動前に自動的にリバース・プロキシを起動できるようにする必要があります。

   NGINXリソースは、基礎となるネットワークCRSリソースに依存して作成され、その名前は、次のコマンドを使用して決定できます。

   $ $GRID_HOME/bin/crsctl stat res -w "TYPE == ora.network.type"|grep NAME
   NAME=ora.net1.network

   1. rootユーザーとして、次のコマンド例を使用して、NGINXを管理するClusterwareリソースを作成します。

      # $GRID_HOME/bin/crsctl add resource nginx -type generic_application
       -attr "ACL='owner:root:rwx,pgrp:root:rwx,other::r--,group:oinstall:r-x,user:oracle:rwx',EXECUTABLE_NAMES=nginx,START_PROGRAM='/bin/systemctl
       start -f nginx',STOP_PROGRAM='/bin/systemctl
       stop -f nginx',CHECK_PROGRAMS='/bin/systemctl
       status nginx' ,START_DEPENDENCIES='hard(ora.net1.network) pullup(ora.net1.network)',
       STOP_DEPENDENCIES='hard(intermediate:ora.net1.network)',
       RESTART_ATTEMPTS=0, HOSTING_MEMBERS='dc1north01,dc1north02', CARDINALITY=2"

      この例で作成したNGINXリソースは、指定した複数のクラスタ・ノード(HOSTING_MEMBERSで指定)で同時に実行されます。これは、GoldenGateサービス・マネージャのデプロイメントが複数構成されており、それらをクラスタ・ノード間で単独で移動できる場合にお薦めします。

   2. NGINX Clusterwareリソースの作成時には、GoldenGateデプロイメントの起動前にNGINXが起動されるように、GoldenGate XAGリソースを変更する必要があります。

      rootユーザーとして、次のコマンド例を使用してXAGリソースを変更します。

      現在の--filesystemsパラメータを確認します。

      # agctl config goldengate GGNORTH | grep "File System"
      
      File System resources needed: dbfsgg

タスク8: Oracle Clusterwareの構成

1. プライマリ・クラスタのXAG GoldenGateインスタンスを変更します。

   rootユーザーとして次のコマンド例を使用して、プライマリ・クラスタ上のOracle Grid Infrastructure Standalone Agent (XAG) GoldenGateインスタンスに変更を加えそれがOracle Data Guard構成の一部であることを特定する必要があります。

   # agctl modify goldengate instance_name --dataguard_autostart yes

2. スタンバイ・クラスタで、「タスク7: Oracle Clusterwareの構成」の手順に従って、次のステップ3から5を実行します。
3. 各スタンバイ・クラスタ・ノードにXAGソフトウェアをインストールします。

   XAGソフトウェアをプライマリ・クラスタと同じディレクトリにインストールすることをお薦めします。

4. XAGのアプリケーションVIPの作成を準備します。

   想定ではこのVIPおよびVIP名はプライマリ・クラスタ上とは異なるため、VIPアドレスをスタンバイ・クラスタのシステム管理者が割り当てる必要があります。

5. Oracle GoldenGate MicroservicesをXAGに登録します。

   Oracle GoldenGate MicroservicesをXAGに登録するために使用するパラメータは、プライマリ・クラスタに登録するときに使用するパラメータと似ています。

   1. 次のコマンドを使用して、プライマリ・クラスタでの現在のパラメータを確認します。

      $ agctl config goldengate GoldenGate_instance_name
      
      Instance name: GoldenGate_instance_name
      Application GoldenGate location is: /u01/oracle/goldengate/gg21c_MS
      Goldengate MicroServices Architecture environment: yes
      Goldengate Service Manager configuration directory:
       /mnt/dbfs/goldengate/deployments/ggnorth_sm/etc/conf
      Goldengate Service Manager var directory:
       /mnt/dbfs/goldengate//deployments/ggnorth_sm/var
      Service Manager Port: 9100
      Goldengate Administration User: oggadmin
      Autostart on DataGuard role transition to PRIMARY: yes
      Configured to run on Nodes: dc1north01,dc1north02
      ORACLE_HOME location is: /u01/oracle/goldengate/gg21c_MS/lib/instantclient
      Database Services needed: ora.ggdg.oggserv_cdb.svc,ora.ggdg.oggserv_pdb.svc
      File System resources needed: dbfsgg,nginx
      VIP name: gg_vip_prmy

      また、XAGパラメータ--filesystem_verify noを指定して、GoldenGateインスタンスの登録時にXAGでDBFSデプロイメント・ディレクトリの存在が確認されないようにする必要があります。このパラメータを設定しないと、スタンバイ・クラスタでDBFSがマウントされないため、XAGの登録に失敗します。

      ノート:

      GoldenGateをXAGに登録するときは、プライマリ・クラスタで使用したのと同じGoldenGateインスタンス名を使用することをお薦めします。

   2. rootユーザーとして、スタンバイ・クラスタでGoldenGateをXAGに登録します。

      # agctl add goldengate GoldenGate_instance_name \
      --gg_home /u01/oracle/goldengate/gg21c_MS \
      --service_manager \
      --config_home /mnt/dbfs/goldengate/deployments/ggnorth_sm/etc/conf \
      --var_home /mnt/dbfs/goldengate/deployments/ggnorth_sm/var \
      --port 9100 \
      --oracle_home /u01/goldengate/gg21c_MS/lib/instantclient \
      --adminuser oggadmin \
      --user oracle \
      --group oinstall \
      --vip_name gg_vip_stby \
      --filesystems dbfsgg,nginx \
      --db_services ora.ggdgs.oggserv_cdb.svc,ora.ggdgs.oggserv_pdb.svc \
      --use_local_services \
      --nodes dc2north01,dc2north02 \
      --filesystem_verify no \
      --dataguard_autostart yes

Oracle Grid Infrastructure Bundled Agentの詳細は、http://www.oracle.com/technetwork/database/database-technologies/clusterware/downloads/xag-agents-downloads-3636484.htmlを参照してください

タスク9: Oracle GoldenGateデータベース接続用のOracle Net TNS別名の作成

「タスク9: Oracle GoldenGateデータベース接続用のOracle Net TNS別名の作成」で示されているIPC通信プロトコルを使用して、プライマリ・クラスタ上でIPCプロトコルを使用してプライマリ・データベース用に作成したのと同じTNS別名を、スタンバイ・クラスタの各ノードで、同じ別名で作成する必要があります。

Oracle GoldenGateデプロイメントで使用されるtnsnames.oraの場所は、スタンバイ・システム・ノード上でもプライマリ・システム上のその場所と同じである必要があります。

次の問合せREST APIコールを使用して、プライマリ・クラスタ上のTNS_ADMINの場所を問い合せます。

$ curl -s -u OGG_admin_username
 https://vip_name/services/v2/deployments/deployment_name
 -XGET|python -m json.tool|grep TNS_ADMIN -A1

Oracle GoldenGateサービス・マネージャ管理者ユーザーのパスワードの入力を求められます。

たとえば:

$ curl -s -u oggadmin https://dc1north01-vip1/services/v2/deployments/ggnorth
 -XGET|python -m json.tool|grep TNS_ADMIN -A1

                "name": "TNS_ADMIN",
                "value": "/u01/goldengate/network/admin"

必ず、tnsnames.oraがスタンバイ・クラスタ・ノードすべてでこの同じディレクトリにあることを確認してください。

GoldenGateデータベースのTNS別名の例:

ggnorth_pdb =
    (DESCRIPTION =
      (SDU = 2097152)
      (ADDRESS = (PROTOCOL = IPC)(KEY=LISTENER))
      (CONNECT_DATA =
        (SERVICE_NAME = oggserv_pdb.example.com)
       )
    )

タスク10: Oracle GoldenGateプロセスの構成

「タスク10: Oracle GoldenGateプロセスの構成」で示されているガイダンスに加え、Extract、分散パスおよびReplicatに関する次の推奨事項に従います。

プライマリ・クラスタでのExtract構成

REDO転送の最大パフォーマンス・モードまたは最大可用性モードを使用しているData Guard構成を使用するGoldenGate Extractプロセスでは、トランザクションが失われて論理データの不整合が発生しないように、プライマリ・クラスタ上のExtractプロセス・パラメータ・ファイルに次のパラメータを追加する必要があります。

TRANLOGOPTIONS HANDLEDLFAILOVER

このパラメータにより、まだData Guardスタンバイ・データベースに適用されていないREDOからExtractがトランザクション・データを抽出しないようにします。これは、Oracle GoldenGateがソース・スタンバイ・データベースに存在しないデータをターゲット・データベースにレプリケートしないようにするために重要です。

このパラメータが指定されていないと、ソース・データベースのデータ損失フェイルオーバー後に、ソース・データベースに存在していないデータがターゲット・データベースに保持される可能性があります。それにより、論理データの不整合が発生します。

デフォルトでは、スタンバイ・データベースで適用されたSCN情報を問い合せることができないためにExtractが停止すると、その60秒後に、警告メッセージがExtractレポート・ファイルに書き込まれます。たとえば:

WARNING OGG-02721 Extractはスタンバイ・データベースを60秒待機しています。

Extractレポート・ファイルに警告メッセージが書き込まれるまでの時間は、ExtractパラメータのTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_WARNINGを使用すると調整できます。

Extractが30分(デフォルト)後にスタンバイ・データベースによって適用されたSCN情報を問い合せることができない場合、Extractプロセスは異常終了して、次のメッセージがExtractレポート・ファイルに記録されます。

ERROR OGG-02722 Extractは、スタンバイ・データベースがアクセス可能になるか、プライマリ・データベースに同期することを1,800秒待機して異常終了しました。

デフォルトのタイムアウトである30分が経過するまでにスタンバイ・データベースが使用可能になると、Extractでソース・データベースからのデータのマイニングが続行され、次のメッセージがレポート・ファイルに報告されます。

INFO OGG-02723 Extractは停止状態から復帰してLCRの処理を開始しました。

タイムアウト値の30分は、ExtractパラメータTRANLOGOPTIONS HANDLEDLFAILOVER STANDBY_ABEND valueを使用して調整できます。ここでのvalueは、スタンバイが使用不可になってから異常終了するまでの秒数です。

計画メンテナンスの停止時など、スタンバイ・データベースが長時間使用できなくなるときに、Extractでプライマリ・データベースからのデータ抽出を続行する場合は、Extractパラメータ・ファイルからTRANLOGOPTIONS HANDLEDLFAILOVERパラメータを削除して、Extractを再起動してください。このパラメータは、スタンバイが使用可能になったら必ず設定してください。

ノート:

スタンバイが使用できない間にプライマリ・データベースからの抽出が続行されていると、スタンバイが使用可能になったときにデータ損失フェイルオーバーが発生し、フェイルオーバーの前にすべてのプライマリREDOが適用されていない可能性もあります。GoldenGateターゲット・データベースには、ソース・データベースに存在しないデータが含まれるようになります。

TRANLOGOPTIONS HANDLEDLFAILOVERパラメータの詳細は、Oracle GoldenGateリファレンス・ガイド(https://docs.oracle.com/en/middleware/goldengate/core/21.3/reference/reference-oracle-goldengate.pdf)を参照してください。

「タスク11: ExtractプロセスとReplicatプロセスの自動起動の構成」の説明に従ってExtractプロセスに自動再起動プロファイルが割り当てられている場合は、Data Guardロール・トランジションの後に、Extractプロセスが自動的に再起動されます。Extractでは、デフォルトのタイムアウト期間である5分が経過するまで、新しいスタンバイ・データベースの現在の状態が無視されて、新しいプライマリ・データベースからのREDOデータのマイニングが続行されます。この期間の経過後にスタンバイが使用できない場合、Extractは次のエラーで異常終了します。

INFO OGG-25053 スタンバイ・データベース復帰のための300秒の待機がタイムアウトです。ただちにHANDLEDLFAILOVERを実施します。

エラーOGG-06219 ロギング・サーバーOGG$CAP_EXT1からデータを抽出できません

ERROR OGG-02078 Extractは処理スレッドで致命的エラーを検出し、異常終了しています。

Extractは、Oracle GoldenGate Microservicesの自動再起動プロファイルに基づいて、再試行回数に達するか新しいスタンバイ・データベースが使用可能になるまで自動的に再起動し、HANDLEDLFAILOVERタイムアウトに達すると失敗します。

データベース・ロール・トランジション後のタイムアウト期間中、HANDLEDLFAILOVERパラメータは自動的に一時停止されるため、ソース・スタンバイ・データベースが最新の状態に維持されていないことの考慮なしに、データがOracle GoldenGateレプリカ・データベースにレプリケートされます。Extractの異常終了前に起動するスタンバイ・データベースのタイムアウト期間は、ExtractパラメータのTRANLOGOPTIONS DLFAILOVER_TIMEOUTを使用すると調整できます。

DLFAILOVER_TIMEOUTをデフォルトの5分のままにして、古いプライマリがスタンバイに変換できるようにすることをお薦めします。新しいスタンバイ・データベースが長期間使用できなくなるか完全に消失した場合に、Extractを起動して実行状態を維持するには、Extractパラメータ・ファイルからHANDLEDLFAILOVERパラメータを削除する必要があります。このパラメータを削除すると、ExtractはREDOがスタンバイ・データベースに適用されるまで待機することなくデータを抽出します。

スタンバイ・データベースがオンラインに戻りプライマリ・データベースからのすべてのREDOが適用されるまでの期間は、

それとOracle GoldenGateレプリカ・データベースとでデータの相違があります。これは、スタンバイ・データベースが最新状態になると解決されます。その時点で、統合Extractプロセス・パラメータ・ファイルにHANDLEDLFAILOVERパラメータを再追加し、Extractを停止してから再起動します。

プライマリ・データベースが失われた場合にブローカでスタンバイ・データベースに自動的にフェイルオーバーできるなど、ファスト・スタート・フェイルオーバーを有効にしてOracle Data Guardが構成されている場合は、次に示す統合Extractパラメータをさらに指定する必要があります。

TRANLOGOPTIONS FAILOVERTARGETDESTID n

このパラメータでは、スタンバイ・データベースにまだ適用されていないREDOデータを抽出しないことに関して、Oracle GoldenGate Extractプロセスを遅らせたままにしておく必要があるスタンバイ・データベースを指定します。

FAILOVERTARGETDESTIDの正しい値を判断するには、ソース・スタンバイ・データベースへのREDOの送信に使用されるGoldenGateソース・データベースのLOG_ARCHIVE_DEST_Nパラメータを使用します。たとえば、LOG_ARCHIVE_DEST_2がスタンバイ・データベースを指している場合は2の値を使用します。

たとえば:

SQL> show parameters log_archive_dest

NAME                  TYPE     VALUE
--------------------- -------- ---------------------------------------------------
log_archive_dest_1    string   location=USE_DB_RECOVERY_FILE_DEST,
                               valid_for=(ALL_LOGFILES, ALL_ROLES)

log_archive_dest_2    string   service="ggnorths", SYNC AFFIRM delay=0
                               optional compression=disable max_failure=0 reopen=300
                               db_unique_name="GGNORTHS" net_timeout=30,
                               valid_for=(online_logfile,all_roles)

この例では、次のようにExtractパラメータを設定します。

TRANLOGOPTIONS FAILOVERTARGETDESTID 2

Extractパラメータ・ファイルにこのパラメータを追加するには、Oracle GoldenGate Administration Serverを使用してExtract詳細の表示を選択します

1. 「管理サービス」タブで、Extractの「アクション」メニューを選択し、「詳細」を選択します。

2. Extract詳細のビューで、「パラメータ」タブを選択してから、鉛筆アイコンを選択して現在のパラメータ・ファイルを編集します

3. TRANLOGOPTIONSパラメータを追加し、変更を保存するために「適用」を選択します。

新しいパラメータを有効にするために、Extractプロセスを停止してから再起動する必要があります。これは管理サーバーを使用して実行できます。

前述のExtract TRANLOGOPTIONSパラメータの詳細は、Oracle GoldenGateのリファレンス(https://docs.oracle.com/en/middleware/goldengate/core/21.3/reference/tranlogoptions.html#GUID-B6ADFEC9-10E6-456D-9477-088513E113AF)を参照してください。

プライマリおよびスタンバイ・クラスタでの分散パス構成

受信サーバーを実行しているOracle GoldenGate環境のターゲット・データベースがOracle Data Guardで保護されている場合、受信サーバーに証跡ファイルを送信する分散パスには重要な考慮事項があります。Oracle Data Guardロール・トランジションの後に受信サーバーを別のクラスタに移動する場合は、新しいターゲット・クラスタ・アドレスを反映するように分散パスを変更する必要があります。

分散パスは、受信サーバー・クラスタにあるターゲット・データベースでデータベース・ロール・トランジション・トリガーを使用して自動的に変更できます。

プライマリ・クラスタとスタンバイ・クラスタのVIPで別々のルートCA証明書が使用されている場合は、「オンプレミス: Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」の説明に従って、スタンバイ証明書をソース・デプロイメントのサービス・マネージャに追加する必要があります。

次の手順に従って、データベース・ロール・トランジション・トリガーを作成します。このトリガーでは、ターゲット・データベースのData Guardロール・トランジションの間の、受信サーバーがプライマリ・システムとスタンバイ・システムの間で移動されるときに、分散パスのターゲット・アドレスが変更されます。

1. 分散パスを変更するシェル・スクリプトを作成します。

   「分散パス・ターゲット変更スクリプトの例」には、分散パス・ターゲット・アドレスの変更に使用できるシェル・スクリプトの例が記載されています。適切な変数値の設定については、スクリプト例のコメントを参照してください。

   このスクリプトは、プライマリ・データベース・クラスタおよびスタンバイ・データベース・クラスタのすべてのOracle RACノードで同じローカル・ディレクトリに配置する必要があります。スクリプト・ファイルの権限は6751に設定します。

   たとえば:

   $ chmod 6751 /u01/oracle/goldengate/scripts/change_path_target.sh

   このシェル・スクリプト例では、REST APIコールを使用してOracle GoldenGate分散パスにアクセスします。このREST APIコールをセキュアにするために、次に示すように、GoldenGateデプロイメント管理者のユーザー名とパスワードを構成ファイル(access.cfg)に含めることをお薦めします。

   $ cat /u01/oracle/goldengate/scripts/access.cfg
   
   user = "oggadmin:<password>"

   access.cfgファイルは、次のデータベース・ロール・トランジション・トリガーでも参照されます。

2. DBMS_SCHEDULERジョブを作成します。

   PL/SQL内からオペレーティング・システム・シェル・スクリプトを実行するために、DBMS_SCHEDULERジョブを作成する必要があります。ルート・コンテナ・データベース(CDB)内にSYSDBAユーザーとしてスケジューラ・ジョブを作成します。

   たとえば:

   SQL> exec dbms_scheduler.drop_job('gg_change_path_target');
   SQL> exec dbms_scheduler.create_job(job_name=>'gg_change_path_target',
    job_type=>'EXECUTABLE', number_of_arguments => 6,
    job_action=>'/u01/oracle/goldengate/scripts/change_path_target.sh',
    enabled=>FALSE);

   外部ジョブを実行するには、$ORACLE_HOME/rdbms/admin/externaljob.oraファイルのパラメータrun_userとrun_groupをOracleデータベースのオペレーティング・システムのユーザーとグループに設定する必要があります。

   たとえば:

   run_user = oracle
   run_group = oinstall

   extrernaljob.oraは、プライマリ・データベース・クラスタおよびスタンバイ・データベース・クラスタのすべてのOracle RACノードで構成する必要があります。

3. データベース・ロール・トランジション・トリガーを作成します。

   次の例を使用して、GoldenGateターゲット・データベースに、スタンバイ・データベースがプライマリ・データベースになったときに起動され分散パスのターゲット・アドレスを変更するロール・トランジション・トリガーを作成します。

   CREATE OR REPLACE TRIGGER gg_change_path
   AFTER db_role_change ON DATABASE
   declare
     role varchar2(30);
     hostname varchar2(64);
   begin
     select database_role into role from v$database;
     select host_name into hostname from v$instance;
   
     DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',1,'source_primary_cluster_VIP');
   
   DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',2,'source_standby_cluster_VIP');
     DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',4,'dist_path_name');
     DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',5,'deployment_name');
     DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',6, '<dir/access.cfg>');
   
     if role = 'PRIMARY' and hostname like 'primary_target_cluster_name%'
     then
   
       DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',3,'primary_target_cluster_VIP:443');
     elsif role = 'PRIMARY'
     then
       DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('gg_change_path_target',3,'standby_target_cluster_VIP:443');
     end if;
     DBMS_SCHEDULER.RUN_JOB(job_name=>'gg_change_path_target');
   end;
   /

   データベース・トリガーを作成した後、次のコマンドを使用して、プライマリ・データベースにあるログ・ファイルを切り替えてコードがスタンバイ・データベースに伝播されるようにします。

   SQL> alter system switch all logfile;

プライマリ・クラスタでのReplicat構成

「オンプレミス: Oracle Real Application Clustersを使用したOracle GoldenGate Microservices Architectureの構成のベスト・プラクティス」で説明されているように、ターゲット・データベース内のチェックポイント表は、すべてのOracle GoldenGate Replicatプロセスに必要です。Oracle Data Guardで構成したReplicatには、その他の構成要件はありません。

分散パス・ターゲット変更スクリプトの例

次のスクリプト例を使用すると、ソースOracle GoldenGateデプロイメントの分散パスのターゲット・アドレスを変更して、Oracle Data Guardロール・トランジションの後の受信サーバーの新しい場所を反映できます。この例では、Data Guardを使用したMAAアーキテクチャでソースGoldenGateデプロイメントが構成されており、分散サーバーをプライマリ・システムとスタンバイ・システムの間で再配置できることを前提としています。

#!/bin/bash

# change_path_target.sh - changes the target host of a GG Distribution Path when the target
#                         moves between primary/standby clusters.
# Example usage:
# ./change_path_target.sh <primary source VIP>:443 <standby source VIP>:443 <path target VIP> <path name> <deployment name> <credentials file>

SOURCE1=$1      # PRIMARY Distribution Server VIP
SOURCE2=$2      # STANDBY Distribution Server VIP
TARGET=$3       # Distribution path target VIP
DPATH=$4        # Distribution path name
DEP=$5          # Deployment name
ACCESS=$6       # access.cfg file containing the deployment credentials. Example contents:
                # user = "oggadmin:<password>"

CONNECT=0

#echo "#${i} - `date`:"
LOGFILE=/tmp/ogg_dpatch_change.txt

result=$(curl -si -K $ACCESS https://$SOURCE1/$DEP/distsrvr/services/v2/sources/$DPATH -X GET| grep HTTP |  awk '{print $2}')

# Will return NULL of nginx not running, 502 if cannot contact server, 200 if contact to server good, and others (404) for other bad reasons:

if [[ -z $result || $result -ne 200 ]]; then  # Managed to access the Distr Server
  echo "`date` - Couldn't contact Distribution Server at $SOURCE1 Deployment $DEP ****" >> $LOGFILE
else # Try the other source host:
  echo "`date` - Got status of Distribution Server at $SOURCE1 Deployment $DEP ***"  >> $LOGFILE
  SOURCE=$SOURCE1
  CONNECT=1
fi

if [ $CONNECT -eq 1 ]; then
# For secure NGINX patch destination (wss)
  PAYLOAD='{"target":{"uri":"wss://'${TARGET}'/services/ggnorth/v2/targets?trail=bb"}}'
  curl -s -K $ACCESS https://$SOURCE/$DEP/distsrvr/services/v2/sources/$DPATH -X PATCH --data '{"status": "stopped"}'

# Set new target for path:
  curl -s -K $ACCESS https://$SOURCE/$DEP/distsrvr/services/v2/sources/$DPATH -X PATCH --data "$PAYLOAD"
  echo "`date` - Set path $DPATH on $SOURCE deployment $DEP:" >> $LOGFILE

  curl -s -K $ACCESS https://$SOURCE/$DEP/distsrvr/services/v2/sources/$DPATH -X GET | python -m json.tool | grep uri >> $LOGFILE
  curl -s -K $ACCESS https://$SOURCE/$DEP/distsrvr/services/v2/sources/$DPATH -X PATCH --data '{"status": "running"}'

exit 0
else
  echo "`date` - ERROR: COULDN'T CHANGE DISTRIBUTION PATH ($DPATH) in Deployement $DEP at $SOURCE! ***" >> $LOGFILE
fi

# If here, means we couldn't connect to either Distribution Servers
exit 1