タスク3: プライマリおよびスタンバイGGHubのためのOracle GoldenGateの構成
ステップ3.1 - Oracle GoldenGateソフトウェアのインストール
Oracle GoldenGateソフトウェアを、GoldenGate構成の一部となるプライマリおよびスタンバイGGHub構成のすべてのノードでローカルにインストールします。インストール・ディレクトリは、すべてのノードで同一にしてください。
次のサブステップを実行して、このステップを完了します。
- ステップ3.1.1 ソフトウェアの解凍とインストール用レスポンス・ファイルの作成
- ステップ3.1.2 Oracle GoldenGateソフトウェアのインストール
- ステップ3.1.3 Oracle GoldenGate Microservices Architecture用のパッチのインストール
ステップ3.1.1 ソフトウェアの解凍とインストール用レスポンス・ファイルの作成
すべてのGGHubノードのoracle
OSユーザーとして、Oracle GoldenGateソフトウェアを解凍します。
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$ unzip -q
/u01/oracle/stage/p36175132_2113000OGGRU_Linux-x86-64.zip -d
/u01/oracle/stage
このソフトウェアには、Oracle Database 21c以前のサポート対象バージョンに対応するレスポンス・ファイルの例が含まれています。レスポンス・ファイルは、すべてのデータベース・ノードへのOracle GoldenGateのインストールに同じファイルを使用できるように共有ファイル・システムにコピーして、次のパラメータを編集します。
INSTALL_OPTION=ora21c
SOFTWARE_LOCATION=/u01/app/oracle/goldengate/gg21c (recommended location)
すべてのGGHubノードのoracle
OSユーザーとして、インストール用のレスポンス・ファイルをコピーして編集します。
[oracle@gghub_prim1 ~]$ cp
/u01/oracle/stage/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/response/oggcore.rsp
/u01/oracle/stage
[oracle@gghub_prim1 ~]$ vi /u01/oracle/stage/oggcore.rsp
# Before
INSTALL_OPTION=
SOFTWARE_LOCATION=
# After
INSTALL_OPTION=ora21c
SOFTWARE_LOCATION=/u01/app/oracle/goldengate/gg21c
ステップ3.1.2 Oracle GoldenGateソフトウェアのインストール
すべてのGGHubノードでoracle
OSユーザーとして、runInstaller
を実行してOracle GoldenGateをインストールします。
[oracle@gghub_prim1 ~]$ cd
/u01/oracle/stage/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/
[oracle@gghub_prim1 ~]$ ./runInstaller -silent -nowait
-responseFile /u01/oracle/stage/oggcore.rsp
Starting Oracle Universal Installer...
Checking Temp space: must be greater than 120 MB. Actual 32755 MB Passed
Checking swap space: must be greater than 150 MB. Actual 16383 MB Passed
Preparing to launch Oracle Universal Installer from
/tmp/OraInstall2022-07-08_02-54-51PM.
Please wait ...
You can find the log of this install session at:
/u01/app/oraInventory/logs/installActions2022-07-08_02-54-51PM.log
Successfully Setup Software.
The installation of Oracle GoldenGate Services was successful.
Please check
'/u01/app/oraInventory/logs/silentInstall2022-07-08_02-54-51PM.log'
for more details.
[oracle@gghub_prim1 ~]$ cat
/u01/app/oraInventory/logs/silentInstall2022-07-08_02-54-51PM.log
The installation of Oracle GoldenGate Services was successful.
ステップ3.1.3 Oracle GoldenGate Microservices Architecture用のパッチのインストール
すべてのGGHubノードのoracle
OSユーザーとして、最新のOPatchをインストールします。
[oracle@gghub_prim1 ~]$ unzip -oq -d
/u01/app/oracle/goldengate/gg21c
/u01/oracle/stage/p6880880_210000_Linux-x86-64.zip
[oracle@gghub_prim1 ~]$ cat >> ~/.bashrc <<EOF
export ORACLE_HOME=/u01/app/oracle/goldengate/gg21c
export PATH=$ORACLE_HOME/OPatch:$PATH
EOF
[oracle@gghub_prim1 ~]$ . ~/.bashrc
[oracle@gghub_prim1 ~]$ opatch lsinventory |grep
'Oracle GoldenGate Services'
Oracle GoldenGate Services 21.1.0.0.0
[oracle@gghub_prim1 Disk1]$ opatch version
OPatch Version: 12.2.0.1.37
OPatch succeeded.
すべてのGGHubノードでoracle
OSユーザーとして、OPatchのprereq
を実行して、パッチの適用前に競合があるかどうかを検証します。
[oracle@gghub_prim1 ~]$ unzip -oq -d /u01/oracle/stage/
/u01/oracle/stage/p35214851_219000OGGRU_Linux-x86-64.zip
[oracle@gghub_prim1 ~]$ cd /u01/oracle/stage/35214851/
[oracle@gghub_prim1 35214851]$ opatch prereq
CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.26
Copyright (c) 2023, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /u01/app/oracle/goldengate/gg21c
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/goldengate/gg21c/oraInst.loc
OPatch version : 12.2.0.1.26
OUI version : 12.2.0.9.0
Log file location :
/u01/app/oracle/goldengate/gg21c/cfgtoollogs/opatch/opatch2023-04-21_13-44-16PM_1.log
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
すべてのGGHubノードでoracle
OSユーザーとして、OPatchを使用してOracle GoldenGate Microservices Architechtureにパッチを適用します。
[oracle@gghub_prim1 35214851]$ opatch apply
Oracle Interim Patch Installer version 12.2.0.1.37
Copyright (c) 2023, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/goldengate/gg21c
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/goldengate/gg21c/oraInst.loc
OPatch version : 12.2.0.1.37
OUI version : 12.2.0.9.0
Log file location :
/u01/app/oracle/goldengate/gg21c/cfgtoollogs/opatch/opatch2023-04-21_19-40-41PM_1.log
Verifying environment and performing prerequisite checks...
OPatch continues with these patches: 35214851
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Please shutdown Oracle instances running out of this ORACLE_HOME on
the local system.
(Oracle Home = '/u01/app/oracle/goldengate/gg21c'
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '35214851' to OH '/u01/app/oracle/goldengate/gg21c'
Patching component oracle.oggcore.services.ora21c, 21.1.0.0.0...
Patch 35214851 successfully applied.
Log file location:
/u01/app/oracle/goldengate/gg21c/cfgtoollogs/opatch/opatch2023-04-21_19-40-41PM_1.log
OPatch succeeded.
[oracle@gghub_prim1 35214851]$ opatch lspatches
35214851;
OPatch succeeded.
ノート:
プライマリおよびスタンバイのGGHubシステムについて、ステップ3.1のすべての手順を繰り返します。ステップ3.2 - クラウド・ネットワークの構成
Oracle GoldenGateが正しく機能するように、プライベートDNSゾーン、VIP、要塞、セキュリティ・リスト、ファイアウォールなどの仮想クラウド・ネットワーク(VCN)のコンポーネントを構成する必要があります。
VCNとセキュリティ・リストの詳細と作成手順は、Oracle Cloud Infrastructure Networkingのドキュメントを参照してください。
次のサブステップを実行して、このステップを完了します。
- ステップ3.2.1 - GGhub用のアプリケーション仮想IPアドレス(VIP)の作成
- ステップ3.2.2 - ポート443のイングレス・ルールの追加
- ステップ3.2.3 - GGhubファイアウォールでポート443を開く
- ステップ3.2.4 - プライマリおよびスタンバイGGHUBシステム間のネットワーク接続の構成
- ステップ3.2.5 - プライベートDNSゾーンのビューとリゾルバの構成
ステップ3.2.1 - GGhub用のアプリケーション仮想IPアドレス(VIP)の作成
専用のアプリケーションVIPは、クラスタのどのノードでサービスがホストされていても同じホスト名を使用してGoldenGate Microservicesにアクセスできるようにするために必要です。VIPはGGHUBシステムに割り当てられ、ノード障害が発生すると自動的に別のノードに移行されます。2つのVIPが必要になります。その1つはプライマリ用、もう1つはスタンバイGGHUB用です。
すべてのGGhubノードのgrid
OSユーザーとして、次のコマンドを実行し、リソースora.net1.network
の同じサブネット内にあるプライベート・エンドポイントのvnicId
を取得します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ crsctl status resource -p -attr NAME,USR_ORA_SUBNET
-w "TYPE = ora.network.type" |sort | uniq
NAME=ora.net1.network
USR_ORA_SUBNET=10.60.2.0
[grid@gghub_prim1 ~]$ curl 169.254.169.254/opc/v1/vnics
[
{
"macAddr": "02:00:17:04:70:AF",
"privateIp": "10.60.2.120",
"subnetCidrBlock": "10.60.2.0/24",
"virtualRouterIp": "10.60.2.1",
"vlanTag": 3085,
"vnicId": "ocid1.vnic.oc1.eu-frankfurt-1.ocid_value"
},
{
"macAddr": "02:00:17:08:69:6E",
"privateIp": "192.168.16.18",
"subnetCidrBlock": "192.168.16.16/28",
"virtualRouterIp": "192.168.16.17",
"vlanTag": 879,
"vnicId": "ocid1.vnic.oc1.eu-frankfurt-1.ocid_value"
}
[grid@gghub_prim2 ~]$ curl 169.254.169.254/opc/v1/vnics
[
{
"macAddr": "00:00:17:00:C9:19",
"privateIp": "10.60.2.148",
"subnetCidrBlock": "10.60.2.0/24",
"virtualRouterIp": "10.60.2.1",
"vlanTag": 572,
"vnicId": "ocid1.vnic.oc1.eu-frankfurt-1.ocid_value"
},
{
"macAddr": "02:00:17:00:84:B5",
"privateIp": "192.168.16.19",
"subnetCidrBlock": "192.168.16.16/28",
"virtualRouterIp": "192.168.16.17",
"vlanTag": 3352,
"vnicId": "ocid1.vnic.oc1.eu-frankfurt-1.ocid_value"
}
ノート:
次のステップでは、GGHUBノードにプライベートIPを割り当てるために、Cloud Shellを使用する必要があります。詳細は、Cloud Shellの使用を参照してください。Cloud Shellのユーザーとして、次のコマンドを実行し、GGHUBノードにプライベートIPを割り当てます。
username@cloudshell:~ (eu-frankfurt-1)$ export node1_vnic=
'ocid1.vnic.oc1.eu-frankfurt-1.abtheljrl5udtgryrscypy5btmlfncawqkjlcql3kkpj64e2lb5xbmbrehkq'
username@cloudshell:~ (eu-frankfurt-1)$ export node2_vnic=
'ocid1.vnic.oc1.eu-frankfurt-1.abtheljre6rf3xoxtgl2gam3lav4vcyftz5fppm2ciin4wzjxucalzj7b2bq'
username@cloudshell:~ (eu-frankfurt-1)$ export ip_address='10.60.2.65'
username@cloudshell:~ (eu-frankfurt-1)$ oci network vnic assign-private-ip
--unassign-if-already-assigned --vnic-id $node1_vnic --ip-address $ip_address
username@cloudshell:~ (eu-frankfurt-1)$ oci network vnic assign-private-ip
--unassign-if-already-assigned --vnic-id $node2_vnic --ip-address $ip_address
Example of the output:
{
"data": {
"availability-domain": null,
"compartment-id": "ocid1.compartment.oc1..ocid_value",
"defined-tags": {},
"display-name": "privateip20230292502117",
"freeform-tags": {},
"hostname-label": null,
"id": "ocid1.privateip.oc1.eu-frankfurt-1.ocid_value",
"ip-address": "10.60.2.65",
"is-primary": false,
"subnet-id": "ocid1.subnet.oc1.eu-frankfurt-1.ocid_value",
"time-created": "2023-07-27T10:21:17.851000+00:00",
"vlan-id": null,
"vnic-id": "ocid1.vnic.oc1.eu-frankfurt-1.ocid_value"
},
"etag": "da972988"
}
最初のGGhubノードでroot
OSユーザーとして、次のコマンドを実行して、Oracle Clusterwareで管理されるアプリケーションVIPを作成します。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# sh /u01/oracle/scripts/add_appvip.sh
Application VIP Name: gghub_prim_vip
Application VIP Address: 10.60.2.65
Using configuration parameter file:
/u01/app/19.0.0.0/grid/crs/install/crsconfig_params
The log of current session can be found at:
/u01/app/grid/crsdata/gghublb1/scripts/appvipcfg.log
ノート:
プライマリおよびスタンバイのGGHUBシステムについて、ステップ3.2.1のすべての手順を繰り返します。ステップ3.2.2 - イングレス・セキュリティ・リスト・ルールの追加
Cloudコンソールを使用して、そのGGhubに割り当てられたVirtual Cloud Network (VCN)に、2つのイングレス・セキュリティ・リスト・ルールを追加します。
一方のイングレス・ルールは、リバース・プロキシとしてNGINXを使用してOracle GoldenGateサービスに接続するための、認可されたソースIPアドレスと任意のソース・ポートからの宛先ポート443でのTCPトラフィック用であり、他方は、ACFSレプリケーションの有効化に必要な、プライマリとスタンバイのGGhubの間でのICMP TYPE 8 (ECHO)を許可するためのものです。詳細は、セキュリティ・リストの使用およびMy Oracle Supportのドキュメント2584309.1を参照してください。
セキュリティ・リストの更新後、リストには次のような値のエントリが登録されます。
-
NGINX - TCP 443
- ソース・タイプ: CIDR
- ソースCIDR: 0.0.0.0/0
- IPプロトコル: TCP
- ソース・ポート範囲: All
- 宛先ポート範囲: 443
- 次のポートに対してTCPトラフィックを許可: 443 HTTPS
- 説明: Oracle GoldenGate 443
-
ACFS - ICMP TYPE 8 (ECHO)
- ソース・タイプ: CIDR
- ソースCIDR: 0.0.0.0/0
- IPプロトコル: ICMP
- 許可: 次の場合のICMPトラフィック: 8エコー
- 説明: ACFSレプリケーションに必要
ステップ3.2.3 - GGhubファイアウォールでポート443を開く
プライマリ・システムとスタンバイ・システムのすべてのGGhubノードのopc
OSユーザーとして、IPTablesに必要なルールを追加します。
[opc@gghub_prim1 ~]$ sudo vi /etc/sysconfig/iptables
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-m comment --comment "Required for access to GoldenGate, Do not remove
or modify. "
-A INPUT -p tcp -m state --state NEW -m tcp --match multiport
--dports 9100:9105 -j ACCEPT -m comment --comment "Required for access
to GoldenGate, Do not remove or modify. "
[opc@gghub_prim1 ~]$ sudo systemctl restart iptables
ノート:
詳細は、Oracle Linuxセキュリティの実装を参照してください。ステップ3.2.4 - プライマリおよびスタンバイGGHUBシステム間のネットワーク接続の構成
Oracle ACFSスナップショットベースのレプリケーションでは、sshをプライマリ・クラスタとスタンバイ・クラスタ間のトランスポートとして使用します。ACFSをサポートするには、クラスタ間のどちらの方向(プライマリ・クラスタからスタンバイ・クラスタ、スタンバイからプライマリ)でもssh
を使用できることが必要です。『Oracle Automatic Storage Management管理者ガイド』のOracle ACFSレプリケーションに使用するためのsshの構成を参照してください。
サブネットがパブリックとプライベートのどちらであるかの詳細や接続の作成手順は、Oracle Cloud Infrastructure Networkingドキュメントの接続の選択肢を参照してください。
ステップ3.2.5 - プライベートDNSゾーンのビューとリゾルバの構成
プライベートDNSゾーンのビューとレコードは、アプリケーションVIPごとに作成する必要があります。これは、プライマリGGHUBがスタンバイGGHUBデプロイメントのVIPホスト名に到達するために必要です。
「プライベートDNSゾーンのビューとリゾルバの構成」のステップに従って、ステップ3.2.1で作成した専用のGGHUBアプリケーション仮想IPアドレス(VIP)ごとに、プライベートDNSゾーンとレコード・エントリを作成します。
任意のGGhubノードでopc
OSユーザーとして、すべてのアプリケーションVIPを解決できることを検証します。
[opc@gghub_prim1 ~]$ nslookup
gghub_prim_vip.frankfurt.goldengate.com |tail -2
Address: 10.60.2.120
[opc@gghub_prim1 ~]$ nslookup
gghub_stby_vip.frankfurt.goldengate.com |tail -2
Address: 10.60.0.185
ステップ3.3 - 同じリージョン内のGGHub間のACFSファイル・システム・レプリケーションの構成
Oracle GoldenGate Microservices Architectureの設計では、インストールとデプロイメントのディレクトリ構造が簡略化されています。インストール・ディレクトリ: ソフトウェア・パッチ適用中の停止時間を最小限に抑えるために、各データベース・ノードのローカル記憶域に配置することが必要です。デプロイメント・ディレクトリ: デプロイメントの作成中にOracle GoldenGate Configuration Assistant (oggca.sh)を使用して作成されます。このディレクトリは、共有ファイル・システムに配置する必要があります。デプロイメント・ディレクトリには、構成、セキュリティ、ログ、パラメータ、証跡およびチェックポイントのファイルが含まれます。Oracle Automatic Storage Management Cluster File System (ACFS)にデプロイメントを配置すると、システム障害が発生した際に、最高のリカバリ性とフェイルオーバー機能が提供されます。クラスタ全体でチェックポイント・ファイルの可用性を確保することは、障害発生後にGoldenGateプロセスが最後に認識された位置から実行を継続できるようにするために不可欠です。
証跡ファイルのディスク領域には、12時間以上の証跡ファイルに対して十分な量を割り当てることをお薦めします。そうすることで、新しい証跡ファイルを受信できないターゲット環境で問題が発生した場合に、証跡ファイルの生成に十分な領域を確保します。12時間に必要な領域の量は、実際の本番データで証跡ファイルの生成率をテストすることでのみ決定できます。GoldenGateプライマリ・データベースまたはシステムのいずれかの長期計画メンテナンス・イベントの緊急対応策を確立する場合は、2日間分の十分なACFS領域を割り当てるようにします。領域使用率の監視は、どれだけの領域が割り当てられていても、常にお薦めします。
ノート:
GoldenGateハブで個別のACFSファイル・システムを使用した複数のサービス・マネージャ・デプロイメントをサポートする場合は、次のステップをファイルACFSファイル・システムごとに繰り返す必要があります。次のサブステップを実行して、このステップを完了します。
- ステップ3.3.1 - ASMファイル・システムの作成
- ステップ3.3.2 - Cluster Ready Services (CRS)リソースの作成
- ステップ3.3.3 - 現在構成されているACFSファイル・システムの確認
- ステップ3.3.4 - ACFSリソースの起動とステータスの確認
- ステップ3.3.5 - ACFSとアプリケーションVIP間のCRS依存関係の作成
- ステップ3.3.6 - SSHデーモンCRSリソースの作成
- ステップ3.3.7 - ACFSレプリケーションの有効化
- ステップ3.3.8 - ACFSレプリケーションCRSアクション・スクリプトの作成
ステップ3.3.1 - ASMファイル・システムの作成
最初のGGHUBノードでgrid
OSユーザーとして、asmcmd
を使用してACFSボリュームを作成します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ asmcmd volcreate -G DATA -s 120G ACFS_GG1
ノート:
決定したサイズ要件に応じて、ファイル・システムのサイズを変更します。最初のGGHUBノードでgrid
OSユーザーとして、asmcmd
を使用して「ボリューム・デバイス」を確認します。
[grid@gghub_prim1 ~]$ asmcmd volinfo -G DATA ACFS_GG1
Diskgroup Name: DATA
Volume Name: ACFS_GG1
Volume Device: /dev/asm/acfs_gg1-256
State: ENABLED
Size (MB): 1228800
Resize Unit (MB): 64
Redundancy: UNPROT
Stripe Columns: 8
Stripe Width (K): 1024
Usage:
Mountpath:
最初のGGHUBノードのgrid
OSユーザーとして、次のmkfs
コマンドでパーティションをフォーマットします。
[grid@gghub_prim1 ~]$ /sbin/mkfs -t acfs /dev/asm/acfs_gg1-256
mkfs.acfs: version = 19.0.0.0.0
mkfs.acfs: on-disk version = 46.0
mkfs.acfs: volume = /dev/asm/acfs_gg1-256
mkfs.acfs: volume size = 128849018880 ( 120.00 GB )
mkfs.acfs: Format complete.
ステップ3.3.2 - Cluster Ready Services (CRS)リソースの作成
すべてのGGHUBノードのopc
OSユーザーとして、ACFSマウント・ポイントを作成します。
[opc@gghub_prim1 ~]$ sudo mkdir -p /mnt/acfs_gg1
[opc@gghub_prim1 ~]$ sudo chown oracle:oinstall /mnt/acfs_gg1
rootユーザーとして、ファイル・システム・リソースを作成します。ACFSの分散ファイル・ロックの実装により、DBFSとは異なり、一度に複数のGGhubノードにACFSをマウントできます。
最初のGGHUBノードでroot
OSユーザーとして、新しいACFSファイル・システム用のCRSリソースを作成します。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]#
cat > /u01/oracle/scripts/add_asm_filesystem.sh <<EOF
# Run as ROOT
$(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/srvctl
add filesystem \
-device /dev/asm/<acfs_volume> \
-volume ACFS_GG1 \
-diskgroup DATA \
-path /mnt/acfs_gg1 -user oracle \
-node gghub_prim1,gghub_prim2 \
-autostart NEVER \
-mountowner oracle \
-mountgroup oinstall \
-mountperm 755
EOF
[root@gghub_prim1 ~]# sh /u01/oracle/scripts/add_asm_filesystem.sh
ステップ3.3.3 - 現在構成されているACFSファイル・システムの確認
最初のGGHUBノードのgrid
OSユーザーとして、次のコマンドを使用してファイル・システムの詳細を確認します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ srvctl config filesystem -volume ACFS_GG1
-diskgroup DATA
Volume device: /dev/asm/acfs_gg1-256
Diskgroup name: data
Volume name: acfs_gg1
Canonical volume device: /dev/asm/acfs_gg1-256
Accelerator volume devices:
Mountpoint path: /mnt/acfs_gg1
Mount point owner: oracle
Mount point group: oinstall
Mount permissions: owner:oracle:rwx,pgrp:oinstall:r-x,other::r-x
Mount users: grid
Type: ACFS
Mount options:
Description:
Nodes: gghub_prim1 gghub_prim2
Server pools: *
Application ID:
ACFS file system is enabled
ACFS file system is individually enabled on nodes:
ACFS file system is individually disabled on nodes:
ステップ3.3.4 - ACFSリソースの起動とステータスの確認
最初のgghubノードのgrid
OSユーザーとして、次のコマンドを使用して、ファイル・システムを起動および確認します。
[grid@gghub_prim1 ~]$ srvctl start filesystem -volume ACFS_GG1
-diskgroup DATA -node `hostname`
[grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1
-diskgroup DATA
ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim1
作成したCRSリソースには、ora.diskgroup_name.volume_name.acfs
という形式を使用した名前が付けられます。前述のファイル・システムの例を使用すると、CRSリソースの名前はora.data.acfs_gg.acfs
になります。
最初のgghubノードのgrid
OSユーザーとして、次のコマンドを使用してCRSのACFSリソースを確認します。
[grid@gghub_prim1 ~]$ crsctl stat res ora.data.acfs_gg1.acfs
NAME=ora.data.acfs_gg1.acfs
TYPE=ora.acfs_cluster.type
TARGET=ONLINE
STATE=ONLINE on gghub_prim1
ステップ3.3.5 - ACFSとアプリケーションVIP間のCRS依存関係の作成
ファイル・システムが必ずVIPと同じOracle GGHubノードにマウントされるようにするには、次のコマンド例を使用して、VIP CRSリソースをACFSリソースへの依存関係として追加します。個別にレプリケートしたACFSファイル・システムごとに、それぞれ専用のVIPを使用します。
- 最初のGGHubノードで
root
OSユーザーとして、次のコマンドを使用して、VIPリソースの現在の起動および停止の依存関係を判別します。[opc@gghub_prim1 ~]$ sudo su - [root@gghub_prim1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/crsctl stat res -w "TYPE co appvip" |grep NAME | cut -f2 -d"=" gghub_prim_vip1 [root@gghub_prim1 ~]# export APPVIP=gghub_prim_vip1 [root@gghub_prim1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/crsctl stat res $APPVIP -f|grep _DEPENDENCIES START_DEPENDENCIES=hard(ora.net1.network) pullup(ora.net1.network) STOP_DEPENDENCIES=hard(intermediate:ora.net1.network)
- 最初のGGHubノードで
root
OSユーザーとして、ACFSファイル・システム名を決定します。[root@gghub_prim1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/crsctl stat res -w "NAME co acfs_gg1" |grep NAME NAME=ora.data.acfs_gg.acfs [root@gghub_prim1 ~]# export ACFS_NAME='ora.data.acfs_gg1.acfs'
- 最初のGGHubノードで
root
OSユーザーとして、VIPリソースの起動および停止の依存関係を変更します。[root@gghub_prim1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/crsctl modify res $APPVIP -attr "START_DEPENDENCIES='hard(ora.net1.network,$ACFS_NAME) pullup(ora.net1.network) pullup:always($ACFS_NAME)',STOP_DEPENDENCIES='hard(intermediate:ora.net1.network,$ACFS_NAME)',HOSTING_MEMBERS=,PLACEMENT=balanced"
- 最初のGGHubノードで
grid
OSユーザーとして、VIPリソースを起動します。[grid@gghub_prim1 ~]$ $(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/bin/crsctl stat res -w "TYPE co appvip" |grep NAME | cut -f2 -d"=" gghub_prim_vip1 [grid@gghub_prim1 ~]$ export APPVIP=gghub_prim_vip1 [grid@gghub_prim1 ~]$ crsctl start resource $APPVIP CRS-2672: Attempting to start 'gghub_prim_vip1' on 'gghub_prim1' CRS-2676: Start of 'gghub_prim_vip1' on 'gghub_prim1' succeeded
ノート:
次のステップに進む前に、両方のGGHubノードにVIPをマウントできることを確認しておいてください。 - 最初のGGHubノードで
grid
OSユーザーとして、VIPリソースを再配置します。[grid@gghub_prim1 ~]$ crsctl relocate resource $APPVIP -f CRS-2673: Attempting to stop 'gghub_prim_vip1' on 'gghub_prim1' CRS-2677: Stop of 'gghub_prim_vip1' on 'gghub_prim1' succeeded CRS-2673: Attempting to stop 'ora.data.acfs_gg1.acfs' on 'gghub_prim1' CRS-2677: Stop of 'ora.data.acfs_gg1.acfs' on 'gghub_prim1' succeeded CRS-2672: Attempting to start 'ora.data.acfs_gg1.acfs' on 'gghub_prim2' CRS-2676: Start of 'ora.data.acfs_gg1.acfs' on 'gghub_prim2' succeeded CRS-2672: Attempting to start 'gghub_prim_vip1' on 'gghub_prim2' CRS-2676: Start of 'gghub_prim_vip1' on 'gghub_prim2' succeeded [grid@gghub_prim1 ~]$ crsctl status resource $APPVIP NAME=gghub_prim_vip1 TYPE=app.appviptypex2.type TARGET=ONLINE STATE=ONLINE on gghub_prim2 [grid@gghub_prim1 ~]$ crsctl relocate resource $APPVIP -f CRS-2673: Attempting to stop 'gghub_prim_vip1' on 'gghub_prim2' CRS-2677: Stop of 'gghub_prim_vip1' on 'gghub_prim2' succeeded CRS-2673: Attempting to stop 'ora.data.acfs_gg1.acfs' on 'gghub_prim2' CRS-2677: Stop of 'ora.data.acfs_gg1.acfs' on 'gghub_prim2' succeeded CRS-2672: Attempting to start 'ora.data.acfs_gg1.acfs' on 'gghub_prim1' CRS-2676: Start of 'ora.data.acfs_gg1.acfs' on 'gghub_prim1' succeeded CRS-2672: Attempting to start 'gghub_prim_vip1' on 'gghub_prim1' CRS-2676: Start of 'gghub_prim_vip1' on 'gghub_prim1' succeeded
- 最初のGGHubノードで
grid
OSユーザーとして、ACFSファイル・システムのステータスを確認します。[grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim1
ステップ3.3.6 - SSHデーモンCRSリソースの作成
ACFSレプリケーションでは、前に作成した仮想IPアドレスを使用する、プライマリ・ファイル・システムとスタンバイ・ファイル・システムとの通信にセキュア・シェル(ssh
)が使用されます。サーバーの再起動時に、VIP CRSリソースの前にssh
デーモンが起動されて、VIPを使用したクラスタへのアクセスが防止されます。次の手順では、仮想IPリソースの起動後にssh
デーモンを再起動する、ssh
再起動CRSリソースを作成します。レプリケートされたファイル・システムごとに、個別のssh
再起動CRSリソースが必要です。
すべてのGGHUBノードでgrid
OSユーザーとして、ssh
デーモンを再起動するためのCRSアクション・スクリプトをコピーします。このスクリプトは、すべてのプライマリおよびスタンバイGGHUBノードの同じ場所に配置します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ unzip /u01/oracle/stage/gghub_scripts_<YYYYMMDD>.zip
-d /u01/oracle/scripts/
Archive: /u01/oracle/stage/gghub_scripts_<YYYYMMDD>.zip
inflating: /u01/oracle/scripts/acfs_primary.scr
inflating: /u01/oracle/scripts/acfs_standby.scr
inflating: /u01/oracle/scripts/sshd_restart.scr
inflating: /u01/oracle/scripts/add_acfs_primary.sh
inflating: /u01/oracle/scripts/add_acfs_standby.sh
inflating: /u01/oracle/scripts/add_nginx.sh
inflating: /u01/oracle/scripts/add_sshd_restart.sh
inflating: /u01/oracle/scripts/reverse_proxy_settings.sh
inflating: /u01/oracle/scripts/secureServices.py
最初のGGHUBノードのroot
OSユーザーとして、次のコマンドを使用してCRSリソースを作成します。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# sh /u01/oracle/scripts/add_sshd_restart.sh
Application VIP Name: gghub_prim_vip
最初のGGHUBノードのgrid
OSユーザーとして、CRSリソースを起動してテストします。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ crsctl stat res sshd_restart
NAME=sshd_restart
TYPE=cluster_resource
TARGET=OFFLINE
STATE=OFFLINE
[grid@gghub_prim1 ~]$ crsctl start res sshd_restart
CRS-2672: Attempting to start 'sshd_restart' on 'gghub_prim1'
CRS-2676: Start of 'sshd_restart' on 'gghub_prim1' succeeded
[grid@gghub_prim1 ~]$ cat /tmp/sshd_restarted
STARTED
[grid@gghubtest1 ~]$ crsctl stop res sshd_restart
CRS-2673: Attempting to stop 'sshd_restart' on 'gghub_prim1'
CRS-2677: Stop of 'sshd_restart' on 'gghub_prim1' succeeded
[grid@gghub1 ~]$ cat /tmp/sshd_restarted
STOPPED
[grid@gghub1 ~]$ crsctl start res sshd_restart
CRS-2672: Attempting to start 'sshd_restart' on 'gghub_prim1'
CRS-2676: Start of 'sshd_restart' on 'gghub_prim1' succeeded
[grid@gghub1 ~]$ crsctl stat res sshd_restart
NAME=sshd_restart
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on gghub_prim1
ステップ3.3.7 - ACFSレプリケーションの有効化
ACFSスナップショットベース・レプリケーションでは、指定されたレプリケーション・ユーザー(通常はgrid
ユーザー)を使用して、プライマリ・ホストとスタンバイ・ホストの間でスナップショットを転送するためにopenssh
が使用されます。
-
プライマリおよびスタンバイ・ハブ・システムの
grid
OSユーザーとして、プライマリ・ノードとスタンバイ・ノードの間のssh接続を構成します。構成手順については、Oracle ACFSレプリケーションに使用するためのsshの構成を参照してください。 - すべてのプライマリおよびスタンバイGGHubノードで
grid
OSユーザーとして、ssh
を使用して、すべてのプライマリ・ノードからスタンバイ・ノードへの接続をテストし、レプリケーション・ユーザーとしてsshを使用して逆方向の接続をテストします。# On the Primary GGhub [grid@gghub_prim1 ~]$ ssh gghub_stby_vip1.frankfurt.goldengate.com hostname gghub_stby1 [grid@gghub_prim2 ~]$ ssh gghub_stby_vip1.frankfurt.goldengate.com hostname gghub_stby1 # On the Standby GGhub [grid@gghub_stby1 ~]$ ssh gghub_prim_vip1.frankfurt.goldengate.com hostname gghub_prim1 [grid@gghub_stby2 ~]$ ssh gghub_prim_vip1.frankfurt.goldengate.com hostname gghub_prim1
- ACFSがマウントされているプライマリおよびスタンバイGGHubノードで
grid
OSユーザーとして、acfsutil
を使用してプライマリ・ノードとスタンバイ・ノードの間の接続をテストします。# On the Primary GGhub [grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim1 [grid@gghub_prim1 ~]$ acfsutil repl info -c -u grid gghub_prim_vip1.frankfurt.goldengate.com gghub_stby_vip1.frankfurt.goldengate.com /mnt/acfs_gg1 A valid 'ssh' connection was detected for standby node gghub_prim_vip1.frankfurt.goldengate.com as user grid. A valid 'ssh' connection was detected for standby node gghub_stby_vip1.frankfurt.goldengate.com as user grid. # On the Standby GGhub [grid@gghub_stby1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_stby1 [grid@gghub_stby1 ~]$ acfsutil repl info -c -u grid gghub_prim_vip1.frankfurt.goldengate.com gghub_stby_vip1.frankfurt.goldengate.com /mnt/acfs_gg A valid 'ssh' connection was detected for standby node gghub_prim_vip1.frankfurt.goldengate.com as user grid. A valid 'ssh' connection was detected for standby node gghub_stby_vip1.frankfurt.goldengate.com as user grid.
- ACFSがマウントされていないGGHubノードから
acfsutil
コマンドを実行すると、想定どおりにエラーACFS-05518が表示されます。次のように、ACFSがマウントされているGGHubを見つけるためにsrvctl status filesytem
を使用し、コマンドを再実行します。[grid@gghub_prim1 ~]$ acfsutil repl info -c -u grid gghub_stby_vip1.frankfurt.goldengate.com gghub_stby_vip1.frankfurt.goldengate.com /mnt/acfs_gg1 acfsutil repl info: ACFS-05518: /mnt/acfs_gg1 is not an ACFS mount point [grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim2 [grid@gghub_prim1 ~]$ ssh gghub_prim2 [grid@gghub_prim2 ~]$ acfsutil repl info -c -u grid gghub_prim_vip1.frankfurt.goldengate.com gghub_stby_vip1.frankfurt.goldengate.com /mnt/acfs_gg1 A valid 'ssh' connection was detected for standby node gghub_prim_vip1.frankfurt.goldengate.com as user grid. A valid 'ssh' connection was detected for standby node gghub_stby_vip1.frankfurt.goldengate.com as user grid.
ノート:
すべてのプライマリ・ノードからすべてのスタンバイ・ノードへの接続と、その逆方向の接続を検証してください。この接続テストにエラーがない場合にのみ続行します。 - ACFSが現在マウントされているスタンバイGGHubノードで
grid
OSユーザーとして、ACFSレプリケーションを初期化します。[grid@gghub_stby1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_stby1 [grid@gghub_stby1 ~]$ /sbin/acfsutil repl init standby -u grid /mnt/acfs_gg1
- ACFSが現在マウントされているプライマリGGHubノードで
grid
OSユーザーとして、ACFSレプリケーションを初期化します。[grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1 -diskgroup DATA ACFS file system /mnt/acfs_gg is mounted on nodes gghub_prim1 [grid@gghub_prim1 ~]$ /sbin/acfsutil repl init primary -C -p grid@gghub_prim_vip1.frankfurt.goldengate.com -s grid@gghub_stby_vip1.frankfurt.goldengate.com -m /mnt/acfs_gg1 /mnt/acfs_gg1
- プライマリおよびスタンバイGGHubノードで
grid
OSユーザーとして、初期化の進行状況が「送信が完了しました」というステータスに変わるまでモニターします。このステータスは、プライマリ・ファイル・システムの初期コピーが完了し、プライマリ・ファイル・システムが現在スタンバイ・ホストにレプリケートされていることを意味します。# On the Primary GGhub [grid@gghub_prim1 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 | grep -i Status Status: Send Completed # On the Standby GGhub [grid@gghub_prim1 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 | grep -i Status Status: Receive Completed
- プライマリおよびスタンバイGGHubノードで
grid
OSユーザーとして、レプリケートされたACFSファイル・システムを確認しモニターします。# On the Primary GGhub [grid@gghub_prim1 ~]$ acfsutil repl util verifystandby /mnt/acfs_gg1 verifystandby returned: 0 # On the Standby GGhub [grid@gghubtest31 ~]$ acfsutil repl util verifyprimary /mnt/acfs_gg1 verifyprimary returned: 0
ノート:
問題が検出されていない場合は、どちらのコマンドも0 (ゼロ)の値を返します。ゼロ以外の値が返された場合は、続行する前に、ACFSレプリケーションに関する一般的な問題のモニター、診断および解決について、「ACFSレプリケーションのトラブルシューティング」を参照してください。 - プライマリGGHubノードで
grid
OSユーザーとして、次のコマンドを使用してACFSレプリケーションのステータスをモニターします。[grid@gghub_prim1 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 Site: Primary Primary hostname: gghub_prim_vip1.frankfurt.goldengate.com Primary path: /mnt/acfs_gg1 Primary status: Running Background Resources: Active Standby connect string: grid@gghub_stby_vip1.frankfurt.goldengate.com Standby path: /mnt/acfs_gg1 Replication interval: 0 days, 0 hours, 0 minutes, 0 seconds Sending primary as of: Fri May 05 12:37:02 2023 Status: Send Completed Lag Time: 00:00:00 Retries made: 0 Last send started at: Fri May 05 12:37:02 2023 Last send completed at: Fri May 05 12:37:12 2023 Elapsed time for last send: 0 days, 0 hours, 0 minutes, 10 seconds Next send starts at: now Replicated tags: Data transfer compression: Off ssh strict host key checking: On Debug log level: 3 Replication ID: 0x4d7d34a
- ACFSが現在マウントされているスタンバイGGHubノードで
grid
OSユーザーとして、次のコマンドを使用してACFSレプリケーションのステータスをモニターします。[grid@gghub_stby1 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 Site: Standby Primary hostname: gghub_prim_vip1.frankfurt.goldengate.com Primary path: /mnt/acfs_gg1 Standby connect string: grid@gghub_stby_vip1.frankfurt.goldengate.com Standby path: /mnt/acfs_gg1 Replication interval: 0 days, 0 hours, 0 minutes, 0 seconds Last sync time with primary: Fri May 05 12:37:02 2023 Receiving primary as of: Fri May 05 12:37:02 2023 Status: Receive Completed Last receive started at: Fri May 05 12:37:02 2023 Last receive completed at: Fri May 05 12:37:07 2023 Elapsed time for last receive: 0 days, 0 hours, 0 minutes, 5 seconds Data transfer compression: Off ssh strict host key checking: On Debug log level: 3 Replication ID: 0x4d7d34a
ステップ3.3.8 - ACFSレプリケーションCRSアクション・スクリプトの作成
プライマリとスタンバイのACFSファイル・システムの状態を判別するには、CRSアクション・スクリプトを使用します。アクション・スクリプトでは、事前定義された間隔で、ファイル・システムの状態がCRSトレース・ファイルcrsd_scriptagent_grid.trc
にレポートされます。このファイルは、GGhubノードの各プライマリ・ファイル・システム上および各スタンバイ・ファイル・システム上のGrid Infrastructureトレース・ファイル・ディレクトリ/u01/app/grid/diag/crs/<node_name>/crs/trace
にあります。
プライマリ・ファイル・システムとスタンバイ・ファイル・システムの両方のクラスタで、2つのスクリプトが必要です。その1つはローカル・プライマリ・ファイル・システムをモニターし、リモート・スタンバイ・ファイル・システムが使用可能かどうかを確認するためのものであり、もう1つはローカル・スタンバイ・ファイル・システムをモニターし、リモート・プライマリ・ファイル・システムの可用性をチェックするためのものです。ACFSのモニタリングを実装するためのスクリプト例が提供されていますが、そのスクリプトは環境に応じて編集する必要があります。
レプリケートされたファイル・システムごとに、専用のアクション・スクリプトacfs_primary
とacfs_standby
が必要になります。
ステップ3.3.8.1 - アクション・スクリプトacfs_primary.scr
acfs_primary
CRSリソースでは、現在のACFSマウントがプライマリ・ファイル・システムであるかどうかをチェックし、スタンバイ・ファイル・システムがアクセス可能なことと、レプリケートされたデータを受信していることを確認します。このリソースは、Oracle GoldenGateがプライマリOracle GoldenGateハブでプロセスを開始できるかどうかを自動的に判断するために使用します。プライマリからスタンバイ・ファイル・システムにアクセスできない場合、このスクリプト例ではスタンバイ・ファイル・システムの検証を複数回試行します。
acfs_primary
CRSリソースは、プライマリとスタンバイの両方のホストで実行されますが、現在のファイル・システムがプライマリ・ファイル・システムであり、スタンバイ・ファイル・システムがアクセス可能な場合にのみ成功を返します。このスクリプトは、すべてのプライマリおよびスタンバイ・ファイル・システム・ノードの同じ場所に配置する必要があります。
次のパラメータには、推奨のデフォルト設定が使用されています。この設定の値は、変更前にテストする必要があります。
-
MOUNT_POINT=/mnt/acfs_gg1 # The replicated ACFS mount point
-
PATH_NAME=$MOUNT_POINT/status/acfs_primary # Must be unique from other mount files
-
ATTEMPTS=3 # Number of attempts to check the remote standby file system
-
INTERVAL=10 # Number of seconds between each attempt
すべてのプライマリおよびスタンバイGGHUBノードのgrid
OSユーザーとして、acfs_primary.scr
スクリプトを環境に適合するように編集します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ vi /u01/oracle/scripts/acfs_primary.scr
ACFSが現在マウントされているプライマリGGhubノードでoracle
OSユーザーとして、次のコマンドを実行してstatusディレクトリを作成します。
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$ mkdir /mnt/acfs_gg1/status
[oracle@gghub_prim1 ~]$ chmod g+w /mnt/acfs_gg1/status
ACFSが現在マウントされているプライマリおよびスタンバイGGHubノードでgrid
OSユーザーとして、次のコマンドを実行して、プライマリおよびスタンバイ・ファイル・システムを監視するためにacfs_primary
アクション・スクリプトを登録します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ sh /u01/oracle/scripts/add_acfs_primary.sh
################################################################################
List of ACFS resources:
ora.data.acfs_gg1.acfs
################################################################################
ACFS resource name: <ora.data.acfs_gg1.acfs>
ACFSが現在マウントされているプライマリGGHubノードでgrid
OSユーザーとして、acfs_primary
リソースを起動しそのステータスをチェックします。
[grid@gghub_prim1 ~]$ crsctl start resource acfs_primary
CRS-2672: Attempting to start 'acfs_primary' on 'gghub_prim1'
CRS-2676: Start of 'acfs_primary' on 'gghub_prim1' succeeded
[grid@gghub_prim1 ~]$ crsctl stat resource acfs_primary
NAME=acfs_primary
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on gghub_prim1
[grid@gghub_prim1 ~]$ grep acfs_primary
/u01/app/grid/diag/crs/`hostname`/crs/trace/crsd_scriptagent_grid.trc
|grep check
2023-05-05 12:57:40.372 :CLSDYNAM:2725328640: [acfs_primary]{1:33562:34377}
[check] Executing action script:
/u01/oracle/scripts/acfs_primary.scr[check]
2023-05-05 12:57:42.376 :CLSDYNAM:2725328640: [acfs_primary]{1:33562:34377}
[check] SUCCESS: STANDBY file system /mnt/acfs_gg1 is ONLINE
ACFSが現在マウントされているスタンバイGGHubノードでgrid
OSユーザーとして、acfs_primary
リソースを起動しそのステータスをチェックします。acfs_primary
は、プライマリGGhubでのみオンラインにする必要があるため、このステップは失敗します。
[grid@gghub_stby1 ~]$ crsctl start res acfs_primary -n `hostname`
CRS-2672: Attempting to start 'acfs_primary' on 'gghub_stby1'
CRS-2674: Start of 'acfs_primary' on 'gghub_stby1' succeeded
CRS-2679: Attempting to clean 'acfs_primary' on 'gghub_stby1'
CRS-2681: Clean of 'acfs_primary' on 'gghub_stby1' succeeded
CRS-4000: Command Start failed, or completed with errors.
[grid@gghub_stby1 ~]$ crsctl stat res acfs_primary
NAME=acfs_primary
TYPE=cluster_resource
TARGET=ONLINE
STATE=OFFLINE
[grid@gghub_stby1 trace]$ grep acfs_primary
/u01/app/grid/diag/crs/`hostname`/crs/trace/crsd_scriptagent_grid.trc
|grep check
2023-05-05 13:09:53.343 :CLSDYNAM:3598239488: [acfs_primary]{1:8532:2106}
[check] Executing action script: /u01/oracle/scripts/acfs_primary.scr[check]
2023-05-05 13:09:53.394 :CLSDYNAM:3598239488: [acfs_primary]{1:8532:2106}
[check] Detected local standby file system
2023-05-05 13:09:53.493 :CLSDYNAM:1626130176: [acfs_primary]{1:8532:2106}
[clean] Clean/Abort -- Stopping ACFS file system type checking...
ノート:
acfs_primary
リソースのステータスは、ACFSファイル・システムがプライマリ・ファイル・システムの場合にのみONLINE
になります。このリソースは、現在プライマリ・クラスタにないノードで起動すると、スタンバイ・ファイル・システムであるため失敗し、エラーが報告されます。このエラーは無視しても問題ありません。このリソースは、ACFSスタンバイ・クラスタではOFFLINE
ステータスになります。
ステップ3.3.8.2 - アクション・スクリプトacfs_standby.scr
acfs_standby
リソースでは、ローカル・ファイル・システムがスタンバイ・ファイル・システムであることをチェックして、リモートのプライマリ・ファイル・システムのステータスを確認します。プライマリ・ファイル・システムの検証が複数回失敗すると(回数はアクション・スクリプトの変数によって制御)、CRSトレース・ファイルcrsd_scriptagent_grid.trc
に警告が出力されます。このファイルは、Grid Infrastructureトレース・ファイル・ディレクトリ/u01/app/grid/diag/CRS/<node_name>/CRS/trace
に配置されています。
このリソースは、プライマリとスタンバイの両方のホストで実行されますが、現在のファイル・システムがスタンバイ・ファイル・システムであり、プライマリ・ファイル・システムがアクセス可能な場合にのみ成功を返します。
次のパラメータには、推奨のデフォルト設定が使用されています。この設定の値は、変更前にテストする必要があります。
-
MOUNT_POINT=/mnt/acfs_gg # This is the replicated ACFS mount point
-
ATTEMPTS=3 # Number of tries to check the remote primary file system
-
INTERVAL=10 # Number of seconds between each attempt
すべてのプライマリおよびスタンバイGGHUBノードのgrid
OSユーザーとして、acfs_standby.scr
スクリプトを環境に適合するように編集します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ vi /u01/oracle/scripts/acfs_standby.scr
ACFSが現在マウントされているプライマリGGHUBノードでgrid
OSユーザーとして、次のコマンドを実行して、プライマリおよびスタンバイ・ファイル・システムをモニタリングするためにacfs_standby
アクション・スクリプトを登録します。
[grid@gghub_prim1 ~]$ crsctl stat res -w "TYPE co appvip"
|grep NAME
NAME=gghub_prim_vip
[grid@gghub_prim1 ~]$ vi /u01/oracle/scripts/add_acfs_standby.sh
crsctl add resource acfs_standby \
-type cluster_resource \
-attr "ACTION_SCRIPT=/u01/oracle/scripts/acfs_standby.scr, \
CHECK_INTERVAL=150, \
CHECK_TIMEOUT=140, \
START_DEPENDENCIES='hard(ora.data.acfs_gg1.acfs,gghub_prim_vip)
pullup:always(ora.data.acfs_gg1.acfs,gghub_prim_vip)', \
STOP_DEPENDENCIES='hard(ora.data.acfs_gg1.acfs,gghub_prim_vip)' \
OFFLINE_CHECK_INTERVAL=300, \
RESTART_ATTEMPTS=0, \
INSTANCE_FAILOVER=0"
[grid@gghub_prim1 ~]$ sh /u01/oracle/scripts/add_acfs_standby.sh
ACFSが現在マウントされているプライマリGGHUBノードでgrid
OSユーザーとして、acfs_standby
リソースを起動しステータスをチェックします。
[grid@gghub_prim1 ~]$ crsctl start res acfs_standby
CRS-2672: Attempting to start 'acfs_standby' on 'gghub_prim1'
CRS-2676: Start of 'acfs_standby' on 'gghub_prim1' succeeded
[grid@gghub_prim1 ~]$ grep acfs_standby
/u01/app/grid/diag/crs/`hostname`/crs/trace/crsd_scriptagent_grid.trc
|egrep 'check|INFO'
2023-05-05 13:22:09.612 :CLSDYNAM:2725328640: [acfs_standby]{1:33562:34709}
[start] acfs_standby.scr starting to check ACFS remote primary at
/mnt/acfs_gg1
2023-05-05 13:22:09.612 :CLSDYNAM:2725328640: [acfs_standby]{1:33562:34709}
[check] Executing action script: /u01/oracle/scripts/acfs_standby.scr[check]
2023-05-05 13:22:09.663 :CLSDYNAM:2725328640: [acfs_standby]{1:33562:34709}
[check] Local PRIMARY file system /mnt/acfs_gg1
ACFSが現在マウントされているスタンバイGGHUBノードでgrid
OSユーザーとして、次のコマンドを実行して、プライマリおよびスタンバイ・ファイル・システムをモニタリングするためにacfs_standby
アクション・スクリプトを登録します。
[grid@gghub_stby1 ~]$ crsctl stat res -w "TYPE co appvip"
|grep NAME
NAME=gghub_stby_vip
[grid@gghub_stby1 ~]$ vi /u01/oracle/scripts/add_acfs_standby.sh
crsctl add resource acfs_standby \
-type cluster_resource \
-attr "ACTION_SCRIPT=/u01/oracle/scripts/acfs_standby.scr, \
CHECK_INTERVAL=150, \
CHECK_TIMEOUT=140, \
START_DEPENDENCIES='hard(ora.data.acfs_gg1.acfs,gghub_stby_vip)
pullup:always(ora.data.acfs_gg1.acfs,gghub_stby_vip)', \
STOP_DEPENDENCIES='hard(ora.data.acfs_gg1.acfs,gghub_stby_vip)' \
OFFLINE_CHECK_INTERVAL=300, \
RESTART_ATTEMPTS=0, \
INSTANCE_FAILOVER=0"
[grid@gghub_stby1 ~]$ sh /u01/oracle/scripts/add_acfs_standby.sh
ACFSが現在マウントされているプライマリGGHUBノードでgrid
OSユーザーとして、acfs_standby
リソースを起動しステータスをチェックします。
[grid@gghub_stby1 ~]$ crsctl start res acfs_standby
CRS-2672: Attempting to start 'acfs_standby' on 'gghub_stby1'
CRS-2676: Start of 'acfs_standby' on 'gghub_stby1' succeeded
[grid@gghub_stby1 ~]$ grep acfs_standby
/u01/app/grid/diag/crs/`hostname`/crs/trace/crsd_scriptagent_grid.trc
|egrep 'check|INFO'
2023-05-05 13:25:20.699 :CLSDYNAM:1427187456: [acfs_standby]{1:8532:2281}
[check] SUCCESS: PRIMARY file system /mnt/acfs_gg1 is ONLINE
2023-05-05 13:25:20.699 : AGFW:1425086208: [ INFO] {1:8532:2281}
acfs_standby 1 1 state changed from: STARTING to: ONLINE
2023-05-05 13:25:20.699 : AGFW:1425086208: [ INFO] {1:8532:2281}
Started implicit monitor for [acfs_standby 1 1]
interval=150000 delay=150000
2023-05-05 13:25:20.699 : AGFW:1425086208: [ INFO] {1:8532:2281}
Agent sending last reply for: RESOURCE_START[acfs_standby 1 1]
ID 4098:8346
ステップ3.3.9 - ACFS GGhubノードの再配置のテスト
Oracle GoldenGateの構成前に、計画的および計画外のACFS GGhubノードの再配置とサーバー・ロール・トランジションをテストすることは、非常に重要です。
プライマリおよびスタンバイGGHUBノードのgrid
OSユーザーとして、次のコマンドを実行して、GGHUBノード間でACFSを再配置します。
[grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1
-diskgroup DATA
ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim1
[grid@gghub_prim1 ~]$ srvctl relocate filesystem -diskgroup DATA
-volume acfs_gg1 -force
[grid@gghub_prim1 ~]$ srvctl status filesystem -volume ACFS_GG1
-diskgroup DATA
ACFS file system /mnt/acfs_gg1 is mounted on nodes gghub_prim2
プライマリおよびスタンバイGGHUBノードのgrid
OSユーザーとして、次のサンプル・コマンドを使用して、ファイル・システムがVIP、sshd_restart
および2つのACFSリソース(acfs_primary
およびacfs_standby
)とともに別のノードにマウントされていることを確認します。
[grid@gghub_prim1 ~]$ crsctl stat res sshd_restart acfs_primary
acfs_standby ora.data.acfs_gg1.acfs sshd_restart -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
acfs_primary
1 ONLINE ONLINE gghub_prim2 STABLE
acfs_standby
1 ONLINE ONLINE STABLE
gghubfad2
1 ONLINE ONLINE gghub_prim2 STABLE
ora.data.acfs_gg1.acfs
1 ONLINE ONLINE gghub_prim2 mounted on /mnt/acfs
_gg1,STABLE
sshd_restart
1 ONLINE ONLINE gghub_prim2 STABLE
--------------------------------------------------------------------------------
[grid@gghub_stby1 ~]$ crsctl stat res sshd_restart acfs_primary acfs_standby
ora.data.acfs_gg1.acfs sshd_restart -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
acfs_primary
1 ONLINE OFFLINE STABLE
acfs_standby
1 ONLINE ONLINE gghub_stby2 STABLE
ora.data.acfs_gg1.acfs
1 ONLINE ONLINE gghub_stby2 mounted on /mnt/acfs
_gg1,STABLE
sshd_restart
1 ONLINE ONLINE gghub_stby2 STABLE
--------------------------------------------------------------------------------
ステップ3.3.10 - プライマリとスタンバイGGhub間のACFSスイッチオーバーのテスト
スタンバイGGHUBノードのgrid
OSユーザーとして、次のコマンドを実行して、プライマリとスタンバイのGGHUB間でのACFSスイッチオーバー(ロール・リバーサル)を発行します。
[grid@gghub_stby2 ~]$ crsctl stat res ora.data.acfs_gg1.acfs
NAME=ora.data.acfs_gg.acfs
TYPE=ora.acfs_cluster.type
TARGET=ONLINE
STATE=ONLINE on gghub_stby2
[grid@gghub_stby2 ~]$ acfsutil repl failover /mnt/acfs_gg1
[grid@gghub_stby2 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1
Site: Primary
Primary hostname: gghub_stby_vip.frankfurt.goldengate.com
Primary path: /mnt/acfs_gg1
Primary status: Running
Background Resources: Active
Standby connect string: gghub_prim_vip.frankfurt.goldengate.com
Standby path: /mnt/acfs_gg1
Replication interval: 0 days, 0 hours, 0 minutes, 0 seconds
Sending primary as of: Fri May 05 13:51:37 2023
Status: Send Completed
Lag Time: 00:00:00
Retries made: 0
Last send started at: Fri May 05 13:51:37 2023
Last send completed at: Fri May 05 13:51:48 2023
Elapsed time for last send: 0 days, 0 hours, 0 minutes, 11 seconds
Next send starts at: now
Replicated tags:
Data transfer compression: Off
ssh strict host key checking: On
Debug log level: 3
Replication ID: 0x4d7d34a
新しいスタンバイGGHUBノード(元のプライマリ)のgrid
OSユーザーとして、次のコマンドを実行して、プライマリとスタンバイのGGHUB間でのACFSスイッチオーバー(ロール・リバーサル)を発行します。このステップはオプションですが、サイトを元のロールに戻すためにお薦めします。
[grid@gghub_prim2 ~]$ crsctl stat res ora.data.acfs_gg1.acfs
NAME=ora.data.acfs_gg1.acfs
TYPE=ora.acfs_cluster.type
TARGET=ONLINE
STATE=ONLINE on gghub_prim2
[grid@gghub_prim2 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 |grep Site
Site: Standby
[grid@gghub_prim2 ~]$ acfsutil repl failover /mnt/acfs_gg1
[grid@gghub_prim2 ~]$ /sbin/acfsutil repl info -c -v /mnt/acfs_gg1 |grep Site
Site: Primary
ステップ3.4 - Oracle GoldenGateデプロイメントの作成
GGHubにOracle GoldenGateソフトウェアをインストールした後のステップでは、Oracle GoldenGate Configuration Assistantを使用して、GoldenGateデプロイメントを作成するためのレスポンス・ファイルを作成します。
Oracle GoldenGate 21cに導入された統合ビルド機能により、単一のデプロイメントで、異なるOracle DatabaseバージョンにアタッチするExtractとReplicatのプロセスを管理できるようになりました。各デプロイメントは、管理サーバーと(オプションの)パフォーマンス・メトリック・サーバーによって作成されます。GoldenGate証跡ファイルを別のハブまたはGoldenGate環境に転送する必要がない場合は、分散サーバーまたは受信サーバーの作成は不要です。
現時点では、Oracle GoldenGateとXAGには2つの制限があります。
- XAGに登録されているサービス・マネージャごとに、単一のデプロイメントのみを管理できます。複数のデプロイメントが必要な場合は、それぞれのデプロイメントに専用のサービス・マネージャを使用する必要があります。Oracle GoldenGateリリース21cでは、様々なバージョンのOracle Databaseに接続するExtractプロセスおよびReplicatプロセスをサポートする単一のデプロイメントが使用されるため、この要件が簡素化されています。
- XAGに登録されている各サービス・マネージャは、別々の
OGG_HOME
ソフトウェア・インストール・ディレクトリに属している必要があります。Oracle GoldenGateを複数回インストールするのではなく、Oracle GoldenGateを1回インストールし、その後はサービス・マネージャのOGG_HOME
ごとにシンボリック・リンクを作成することをお薦めします。シンボリック・リンクおよびOGG_HOME
環境変数は、すべてのOracle RACノードで、Oracle GoldenGate Configuration Assistantを実行する前に構成する必要があります。
-
レスポンス・ファイルの作成
サイレント構成の場合は、次のサンプル・ファイルをコピーして、oracleユーザーがアクセスできる場所に貼り付けます。次の値を適切に編集します。
CONFIGURATION_OPTION
DEPLOYMENT_NAME
ADMINISTRATOR_USER
SERVICEMANAGER_DEPLOYMENT_HOME
OGG_SOFTWARE_HOME
OGG_DEPLOYMENT_HOME
ENV_TNS_ADMIN
OGG_SCHEMA
レスポンス・ファイル例(
oggca.rsp
):ACFSが現在マウントされているプライマリGGHUBノードで
oracle
OSユーザーとして、Oracle GoldenGateデプロイメントを作成するためのレスポンス・ファイルoggca.rsp
を作成および編集します。[opc@gghub_prim1 ~]$ sudo su - oracle [oracle@gghub_prim1 ~]$ vi /u01/oracle/stage/oggca.rsp oracle.install.responseFileVersion=/oracle/install/rspfmt_oggca_response_schema_v21_1_0 CONFIGURATION_OPTION=ADD DEPLOYMENT_NAME=gghub1 ADMINISTRATOR_USER=oggadmin ADMINISTRATOR_PASSWORD=<password_for_oggadmin> SERVICEMANAGER_DEPLOYMENT_HOME=/mnt/acfs_gg1/deployments/ggsm01 HOST_SERVICEMANAGER=localhost PORT_SERVICEMANAGER=9100 SECURITY_ENABLED=false STRONG_PWD_POLICY_ENABLED=true CREATE_NEW_SERVICEMANAGER=true REGISTER_SERVICEMANAGER_AS_A_SERVICE=false INTEGRATE_SERVICEMANAGER_WITH_XAG=true EXISTING_SERVICEMANAGER_IS_XAG_ENABLED=false OGG_SOFTWARE_HOME=/u01/app/oracle/goldengate/gg21c OGG_DEPLOYMENT_HOME=/mnt/acfs_gg1/deployments/gg01 ENV_LD_LIBRARY_PATH=${OGG_HOME}/lib/instantclient:${OGG_HOME}/lib ENV_TNS_ADMIN=/u01/app/oracle/goldengate/network/admin FIPS_ENABLED=false SHARDING_ENABLED=false ADMINISTRATION_SERVER_ENABLED=true PORT_ADMINSRVR=9101 DISTRIBUTION_SERVER_ENABLED=true PORT_DISTSRVR=9102 NON_SECURE_DISTSRVR_CONNECTS_TO_SECURE_RCVRSRVR=false RECEIVER_SERVER_ENABLED=true PORT_RCVRSRVR=9103 METRICS_SERVER_ENABLED=true METRICS_SERVER_IS_CRITICAL=false PORT_PMSRVR=9104 UDP_PORT_PMSRVR=9105 PMSRVR_DATASTORE_TYPE=BDB PMSRVR_DATASTORE_HOME=/u01/app/oracle/goldengate/datastores/gghub1 OGG_SCHEMA=ggadmin
-
Oracle GoldenGateデプロイメントの作成
ACFSが現在マウントされているプライマリGGHUBノードで
oracle
OSユーザーとして、oggca.sh
を実行してGoldenGateデプロイメントを作成します。[opc@gghub_prim1 ~]$ sudo su - oracle [oracle@gghub_prim1 ~]$ export OGG_HOME=/u01/app/oracle/goldengate/gg21c [oracle@gghub_prim1 ~]$ $OGG_HOME/bin/oggca.sh -silent -responseFile /u01/oracle/stage/oggca.rsp Successfully Setup Software.
-
Oracle GoldenGateデータストアとTNS_ADMINディレクトリの作成
プライマリ・システムとスタンバイ・システムのすべてのGGHUBノードで
oracle
OSユーザーとして、次のコマンドを実行して、Oracle GoldenGateデータストアとTNS_ADMIN
ディレクトリを作成します。[opc@gghub_prim1 ~]$ sudo su - oracle [oracle@gghub_prim1 ~]$ mkdir -p /u01/app/oracle/goldengate/network/admin [oracle@gghub_prim1 ~]$ mkdir -p /u01/app/oracle/goldengate/datastores/gghub1
ステップ3.5 - Oracle Grid Infrastructure Agent (XAG)の構成
次のステップごとの手順では、Oracle Grid Infrastructure Standalone Agent (XAG)を使用してGoldenGateを管理するようにOracle Clusterwareを構成する方法を示します。XAGを使用することで、Oracle GGhubノード間での再配置時に、ACFSファイル・システムのマウントとGoldenGateデプロイメントの停止および起動を自動化します。
ステップ3.5.1 - Oracle Grid Infrastructure Standalone Agentのインストール
XAGソフトウェアは、スタンドアロン・エージェントとしてGrid InfrastructureのORACLE_HOME
の外部にインストールすることをお薦めします。これにより、入手可能な最新のXAGリリースを使用できるようになり、Grid Infrastructureに影響を与えることなくソフトウェアを更新できます。
Oracle Grid Infrastructureホーム・ディレクトリの外部に、XAGスタンドアロン・エージェントをインストールします。XAGは、GoldenGateがインストールされているシステム内のすべてのGGhubノードで同じディレクトリにインストールする必要があります。
プライマリ・システムとスタンバイ・システムの最初のGGHubノードでgrid
OSユーザーとして、ソフトウェアを解凍し、xagsetup.sh
を実行します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ unzip /u01/oracle/stage/p31215432_190000_Generic.zip
-d /u01/oracle/stage
[grid@gghub_prim1 ~]$ /u01/oracle/stage/xag/xagsetup.sh --install
--directory /u01/app/grid/xag --all_nodes
Installing Oracle Grid Infrastructure Agents on: gghub_prim1
Installing Oracle Grid Infrastructure Agents on: gghub_prim2
Updating XAG resources.
Successfully updated XAG resources.
プライマリ・システムとスタンバイ・システムのすべてのGGHUBノードでgrid
OSユーザーとして、新しくインストールしたXAGソフトウェアの場所をPATH変数に追加して、grid
ユーザーがマシンにログオンしたときにagctl
の場所が認識されるようにします。
[grid@gghub_prim1 ~]$ vi ~/.bashrc
PATH=/u01/app/grid/xag/bin:$PATH:/u01/app/19.0.0.0/grid/bin; export PATH
ノート:
正しいagctl
バイナリが見つかるように、Grid Infrastructureのbinディレクトリの前にXAGのbinディレクトリが指定されていることを必ず確認してください。これは、Bashシェル使用時の.bashrcファイルなど、ログオン時に有効になるgridユーザー環境で設定する必要があります。
次の手順では、Oracle Grid Infrastructure Standalone Agent (XAG)を使用してOracle GoldenGateを管理するようにOracle Clusterwareを構成する方法を示します。XAGを使用することで、Oracle GGhubノード間での再配置時に、共有ファイル・システムのマウントとOracle GoldenGateデプロイメントの停止および起動を自動化します。
Oracle GoldenGateは、データベースの起動時およびファイル・システムのマウント時に自動的にデプロイメントが起動および停止されるように、XAGに登録しておく必要があります。
Oracle GoldenGate Microservices ArchitectureをXAGに登録するには、次のコマンド形式を使用します。
agctl add goldengate <instance_name>
--gg_home <GoldenGate_Home>
--service_manager
--config_home <GoldenGate_SvcMgr_Config>
--var_home <GoldenGate_SvcMgr_Var Dir>
--port <port number>
--oracle_home <$OGG_HOME/lib/instantclient>
--adminuser <OGG admin user>
--user <GG instance user>
--group <GG instance group>
--file systems <CRS_resource_name>
--db_services <service_name>
--use_local_services
--attribute START_TIMEOUT=60
説明:
--gg_home
では、GoldenGateソフトウェアの場所を指定します。--service_manager
では、これがGoldenGate Microservicesインスタンスであることを示します。--config_home
では、GoldenGateデプロイメント構成のホーム・ディレクトリを指定します。--var_home
では、GoldenGateデプロイメント変数のホーム・ディレクトリを指定します。--oracle_home
では、Oracle Instant Clientホームを指定します--port
では、デプロイメント・サービス・マネージャのポート番号を指定します。--adminuser
では、GoldenGate Microservices管理者のアカウント名を指定します。--user
では、GoldenGateデプロイメントを所有するオペレーティング・システム・ユーザーの名前を指定します。--group
では、GoldenGateデプロイメントを所有するオペレーティング・システム・グループの名前を指定します。--filesystems
では、そのデプロイメントの起動前にオンラインになっている必要があるCRSファイル・システム・リソースを指定します。これは、前のステップで作成したacfs_primaryリソースになります。-
--filesystem_verify
では、config_home
パラメータとvar_home
パラメータで指定したディレクトリの存在をXAGで確認するかどうかを指定します。アクティブなACFSプライマリ・ファイル・システムについてはこれをyes
に設定する必要があります。スタンバイ・クラスタにGoldenGateインスタンスを追加するときは、no
を指定します。 -
--filesystems_always
では、--filesystems
パラメータで指定したファイル・システムCRSリソースと同じGGhubノードでXAGによってGoldenGateサービス・マネージャが起動されるようにすることを指定します。 --attributes
では、リソースのターゲット・ステータスがオンラインであることを示します。これは、acfs_primary
リソースの起動時に自動的にGoldenGateデプロイメントを起動するために必要です。
GoldenGateデプロイメントは、読取り/書込みモードまたは読取り専用モードでACFSがマウントされているプライマリおよびスタンバイGGHUBに登録する必要があります。
プライマリ・システムとスタンバイ・システムの最初のGGHUBノードでgrid
OSユーザーとして、次のコマンドを実行して、ファイル・システムがマウントされているクラスタのノードを調べます。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ crsctl stat res acfs_standby |grep STATE
STATE=ONLINE on gghub_prim1
ステップ3.5.2.1 - プライマリOracle GoldenGate Microservices ArchitectureのXAGへの登録
プライマリGGHUBの最初のノードでroot
OSユーザーとして、次のコマンド形式を使用して、XAGにOracle GoldenGate Microservices Architectureを登録します。
[opc@gghub_prim1 ~]$ sudo su - root
[root@gghub_prim1 ~]# vi /u01/oracle/scripts/add_xag_goldengate.sh
# Run as ROOT:
/u01/app/grid/xag/bin/agctl add goldengate gghub1 \
--gg_home /u01/app/oracle/goldengate/gg21c \
--service_manager \
--config_home /mnt/acfs_gg1/deployments/ggsm01/etc/conf \
--var_home /mnt/acfs_gg1/deployments/ggsm01/var \
--oracle_home /u01/app/oracle/goldengate/gg21c/lib/instantclient \
--port 9100 \
--adminuser oggadmin \
--user oracle \
--group oinstall \
--filesystems acfs_primary \
--filesystems_always yes \
--filesystem_verify yes \
--attribute TARGET_DEFAULT=online
[root@gghub_prim1 ~]# sh /u01/oracle/scripts/add_xag_goldengate.sh
Enter password for 'oggadmin' : ##########
プライマリGGHUBの最初のノードでgrid
OSユーザーとして、Oracle GoldenGate Microservices ArchitectureがXAGに登録されていることを確認します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl status goldengate
Goldengate instance 'gghub1' is not running
ステップ3.5.2.2 - スタンバイOracle GoldenGate Microservices ArchitectureのXAGへの登録
スタンバイGGHUBの最初のノードでroot
OSユーザーとして、次のコマンド形式を使用して、XAGにOracle GoldenGate Microservices Architectureを登録します。
[opc@gghub_stby1 ~]$ sudo su - root
[root@gghub_stby1 ~]# vi /u01/oracle/scripts/add_xag_goldengate.sh
# Run as ROOT:
/u01/app/grid/xag/bin/agctl add goldengate gghub1 \
--gg_home /u01/app/oracle/goldengate/gg21c \
--service_manager \
--config_home /mnt/acfs_gg1/deployments/ggsm01/etc/conf \
--var_home /mnt/acfs_gg1/deployments/ggsm01/var \
--oracle_home /u01/app/oracle/goldengate/gg21c/lib/instantclient \
--port 9100 --adminuser oggadmin --user oracle --group oinstall \
--filesystems acfs_primary \
--filesystems_always yes \
--filesystem_verify no \
--attribute TARGET_DEFAULT=online
[root@gghub_stby1 ~]# sh /u01/oracle/scripts/add_xag_goldengate.sh
Enter password for 'oggadmin' : ##########
ノート:
スタンバイ・クラスタにGoldenGateインスタンスを追加するときは、--filesystem_verify no
を指定します。
スタンバイGGHUBの最初のノードでgrid
OSユーザーとして、Oracle GoldenGate Microservices ArchitectureがXAGに登録されていることを確認します。
[opc@gghub_stby1 ~]$ sudo su - grid
[grid@gghub_stby1 ~]$ agctl status goldengate
Goldengate instance 'gghub1' is not running
ステップ3.5.3 - Oracle GoldenGateデプロイメントの起動
次に、XAGでGoldenGateデプロイメントを管理するために使用するいくつかのagctlコマンドの例を示します。
プライマリGGHUBの最初のノードでgrid
OSユーザーとして、次のコマンドを実行して、Oracle GoldenGateデプロイメントを起動し確認します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl start goldengate gghub1
[grid@gghub_prim1 ~]$ agctl status goldengate
Goldengate instance 'gghub1' is running on gghub_prim1
最初のGGHUBノードでgrid
OSユーザーとして、次のコマンドを実行して、Oracle GoldenGateリソースの構成パラメータを検証します。
[grid@gghub_prim1 ~]$ agctl config goldengate gghub1
Instance name: gghub1
Application GoldenGate location is: /u01/app/oracle/goldengate/gg21c
Goldengate MicroServices Architecture environment: yes
Goldengate Service Manager configuration directory:
/mnt/acfs_gg1/deployments/ggsm01/etc/conf
Goldengate Service Manager var directory:
/mnt/acfs_gg1/deployments/ggsm01/var
Service Manager Port: 9100
Goldengate Administration User: oggadmin
Autostart on DataGuard role transition to PRIMARY: no
ORACLE_HOME location is:
/u01/app/oracle/goldengate/gg21c/lib/instantclient
File System resources needed: acfs_primary
CRS additional attributes set: TARGET_DEFAULT=online
詳細は、Oracle Grid Infrastructure Bundled Agentを参照してください。
ステップ3.6 - NGINXリバース・プロキシの構成
GoldenGateリバース・プロキシ機能を使用すると、GoldenGateデプロイメントに関連付けられたすべてのGoldenGateマイクロサービスに対応する単一のアクセス先を使用できます。リバース・プロキシを使用しないと、GoldenGateデプロイメント・マイクロサービスは、ホスト名またはIPアドレスと個別のポート番号で構成されるサービスごとに1つずつのURLを使用してアクセスされます。たとえば、サービス・マネージャにアクセスするためにhttp://gghub.example.com:9100を使用し、管理サーバーにはhttp://gghub.example.com:9101、2番目のサービス・マネージャにはhttp://gghub.example.com:9110を使用してアクセスするようになります。
Grid Infrastructure Agent (XAG)を使用してOracle Exadata Database Serviceで高可用性(HA)構成のOracle GoldenGateを実行する場合、GoldenGateサービス・マネージャでは複数のデプロイメントを管理できないとう制限があります。この制限のため、サービス・マネージャ/デプロイメントのペアごとに、個別の仮想IPアドレス(VIP)を作成するようにお薦めします。このようにすると、VIPを使用してマイクロサービスに直接アクセスできます。
リバース・プロキシにより、ポート番号はデプロイメント名とホスト名のVIPに置き換えられるため、マイクロサービスに接続するためのポート番号は不要になります。たとえば、コンソールにWebブラウザ経由で接続するには、次のURLを使用します。
GoldenGateサービス | URL |
---|---|
サービス・マネージャ | https://localhost:localPort |
管理サーバー | https://localhost:localPort/instance_name/adminsrvr |
分散サーバー | https://localhost:localPort/instance_name/distsrvr |
パフォーマンス・メトリック・サーバー | https://localhost:localPort/instance_name/pmsrvr |
レシーバ・サーバー | https://localhost:localPort/instance_name/recvsrvr |
ノート:
OCIでOracle GoldenGateに接続する場合は、要塞(ステップ3.2を参照)とSSHポート転送セッション(ステップ4.1を参照)を作成する必要があります。この後は、https://locahost:localPortを使用するとOracle GoldenGateサービスに接続できます。リバース・プロキシは、マイクロサービスに簡単にアクセスし、セキュリティと管理性を強化するために必須です。
複数のサービス・マネージャを実行する場合は、次の手順によって、サービス・マネージャごとに個別のVIPを使用する構成を用意します。NGINXは、VIPを使用してHTTPS接続リクエストのルーティング先になるサービス・マネージャを決定します。
SSL証明書は、クライアントがNGINX経由で接続するサーバーを認証するために必要です。続行する前に、システム管理者に連絡して、会社の標準に従ってサーバー証明書を作成または取得してください。VIPとサービス・マネージャのペアごとに、個別の証明書が必要です。
ノート:
CA署名付き証明書の共通名は、NGINXで使用されるターゲット・ホスト名/VIPと一致している必要があります。手順に従って、SSL接続のNGINXリバース・プロキシをインストールおよび構成し、すべての外部通信をセキュアにします。
ステップ3.6.1 - セキュアなデプロイメントの要件(証明書)
セキュアなデプロイメントでは、RESTful APIコールを発行し、証跡データをSSL/TLSを介してDistribution ServerとReceiver Server間で転送します。認証局(CA)から取得した既存のビジネス証明書を使用するか、独自の証明書を作成できます。続行する前に、システム管理者に連絡して、会社の標準に従ってサーバー証明書を作成または取得してください。VIPとサービス・マネージャのペアごとに、個別の証明書が必要です。
ステップ3.6.2 - NGINXリバース・プロキシ・サーバーのインストール
すべてのGGHUBノードでroot
OSユーザーとして、次の内容でファイル/etc/yum.repos.d/nginx.repo
を作成することでyum
リポジトリを設定します。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# cat > /etc/yum.repos.d/nginx.repo <<EOF
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/rhel/7/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF
すべてのGGHUBノードでroot
OSユーザーとして、次のコマンドを実行してNGINXをインストール、有効化および起動します。
[root@gghub_prim1 ~]# yum install -y python-requests python-urllib3 nginx
[root@gghub_prim1 ~]# systemctl enable nginx
すべてのGGHUBノードでroot
OSユーザーとして、ソフトウェアのインストール後にNGINXリポジトリを無効にします。
[root@gghub_prim1 ~]# yum-config-manager --disable nginx-stable
ステップ3.6.3 - NGINX構成ファイルの作成
Oracle GoldenGate Microservices Architectureは、リバース・プロキスを使用するように構成できます。Oracle GoldenGate MAには、ReverseProxySettings
というスクリプトが含まれています。このスクリプトにより、NGINXリバース・プロキシ・サーバー専用の構成ファイルが生成されます。
このスクリプトには次のパラメータが必要です。
- --userパラメータは、初期デプロイメントの作成で指定したGoldenGate管理者アカウントの写しにする必要があります。
- GoldenGate管理者パスワードの入力が求められます。
- --portパラメータで指定したリバース・プロキシ・ポート番号は、デフォルトのHTTPSポート番号(443)にする必要があります。ただし、同じ--hostを使用して複数のGoldenGateサービス・マネージャを実行している場合を除きます。その場合は、前のサービス・マネージャ・リバース・プロキシ構成と競合しないHTTPSポート番号を指定します。たとえば、同じホスト名/VIPを使用して2つのサービス・マネージャを実行する場合、最初のリバース・プロキシ構成は'--port 443 --host hostvip01'で作成し、2番目は'--port 444 --host hostvip01'で作成します。個別のホスト名/VIPを使用する場合は、'--port 443 --host hostvip01'と'--port 443 --host hostvip02'を使用して、2つのサービス・マネージャ・リバース・プロキシ構成を作成します。
- 最後に、HTTPポート番号(9100)は、デプロイメントの作成時に指定したサービス・マネージャのポート番号と一致する必要があります。
このステップは、追加のGoldenGateサービス・マネージャごとに繰り返します。
最初のGGHUBノードでoracle
OSユーザーとして、次のコマンドを使用してOracle GoldenGate NGINX構成ファイルを作成します。
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$ export OGG_HOME=/u01/app/oracle/goldengate/gg21c
[oracle@gghub_prim1 ~]$ export PATH=$PATH:$OGG_HOME/bin
[oracle@gghub_prim1 ~]$ cd /u01/oracle/scripts
[oracle@gghub_prim1 ~]$ $OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings
--user oggadmin --port 443 --output ogg_<gghub1>.conf http://localhost:9100
--host <VIP hostname>
Password: <oggadmin_password>
ステップ3.6.4 - NGINX構成ファイルの変更
複数のGoldenGateサービス・マネージャが同じHTTPS 443ポートのIP/VIPを使用するように構成されている場合は、前のステップで生成したNGINXリバース・プロキシ構成ファイルに小さな変更が必要です。同じポート番号を共有するすべてのサービス・マネージャは、--host
パラメータで指定したそれぞれのVIP/IPを使用して個別にアクセスされます。
最初のGGHUBノードでoracle
OSユーザーとして、リバース・プロキシ構成ファイルにリストされている、このサービス・マネージャで管理するデプロイメントの名前を調べて、"_ServiceManager"の出現箇所すべてを、アンダースコアの前にデプロイメント名を付加することで変更します。
[oracle@gghub_prim1 ~]$ cd /u01/oracle/scripts
[oracle@gghub_prim1 ~]$ grep "Upstream Servers" ogg_<gghub1>.conf
## Upstream Servers for Deployment 'gghub1'
[oracle@gghub_prim1 ~]$ sed -i 's/_ServiceManager/<gghub1>_ServiceManager/'
ogg_<gghub1>.conf
ステップ3.6.5 - NGINXのサーバー証明書のインストール
最初のGGHUBノードでroot
OSユーザーとして、ファイル権限400 (-r--------)があるroot
が所有する/etc/nginx/ssl
ディレクトリにサーバー証明書とキー・ファイルをコピーします。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# mkdir /etc/nginx/ssl
[root@gghub_prim1 ~]# cp <ssl_keys> /etc/nginx/ssl/.
[root@gghub_prim1 ~]# chmod 400 /etc/nginx/ssl
[root@gghub_prim1 ~]# ll /etc/nginx/ssl
-r-------- 1 root root 2750 May 17 06:12 gghub1.chained.crt
-r-------- 1 root root 1675 May 17 06:12 gghub1.key
最初のGGHUBノードでoracle
OSユーザーとして、リバース・プロキシ構成ファイルごとに、その証明書およびキー・ファイルの正しいファイル名を設定します。
[root@gghub_prim1 ~]$ vi /u01/oracle/scripts/ogg_<gghub1>.conf
# Before
ssl_certificate /etc/nginx/ogg.pem;
ssl_certificate_key /etc/nginx/ogg.pem;
# After
ssl_certificate /etc/nginx/ssl/gghub1.chained.crt;
ssl_certificate_key /etc/nginx/ssl/gghub1.key;
CA署名付き証明書を使用する場合、ssl_certificate NGINXパラメータで指定した証明書には、1) CA署名付き証明書、2)中間証明書および3)ルート証明書を単一ファイルに含める必要があります。この順序は重要です。そうしていないと、NGINXの起動は失敗して、エラー・メッセージが表示されます。
(SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)
ルート証明書と中間証明書は、CA署名付き証明書プロバイダからダウンロードできます。
最初のGGHUBノードでroot
OSユーザーとして、次のコマンド例を使用してSSL証明書の単一ファイルを生成します。
[root@gghub_prim1 ~]# cd /etc/nginx/ssl
[root@gghub_prim1 ~]# cat CA_signed_cert.crt
intermediate.crt root.crt > gghub1.chained.crt
ssl_certificate_key
ファイルは、CA署名付き証明書をリクエストする際に必要になる証明書署名リクエスト(CSR)の作成時に生成されます。
ステップ3.6.6 - NGINX構成ファイルのインストール
最初のGGhubノードでroot
OSユーザーとして、デプロイメント構成ファイルを/etc/nginx/conf.d
ディレクトリにコピーし、デフォルトの構成ファイルを削除します。
[root@gghub_prim1 ~]# cp /u01/oracle/scripts/ogg_<gghub1>.conf
/etc/nginx/conf.d
[root@gghub_prim1 ~]# rm /etc/nginx/conf.d/default.conf
最初のGGHUBノードでroot
OSユーザーとして、NGINX構成ファイルを検証します。ファイルにエラーがある場合は、次のコマンドでエラーが報告されます。
[root@gghub_prim1 ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginxconf test is successful
最初のGGHUBノードでroot
OSユーザーとして、NGINXを再起動して新しい構成をロードします。
[root@gghub_prim1 ~]# systemctl restart nginx
ステップ3.6.7 - GoldenGate Microservicesの接続のテスト
最初のGGHUBノードでroot
OSユーザーとして、デプロイメントのユーザー名とパスワードが含まれているcurl構成ファイル(access.cfg
)を作成します。
[root@gghub_prim1 ~]# vi access.cfg
user = "oggadmin:<password>"
[root@gghub_prim1 ~]# curl -svf
-K access.cfg https://<VIP hostname>:<port#>/services/v2/config/health
-XGET && echo -e "\n*** Success"
Sample output:
* About to connect() to gghub_prim_vip.frankfurt.goldengate.com port 443 (#0)
* Trying 10.40.0.75...
* Connected to gghub_prim_vip.frankfurt.goldengate.com (10.40.0.75) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* skipping SSL peer certificate verification
* NSS: client certificate not found (nickname not specified)
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=gghub_prim_vip.frankfurt.goldengate.com,OU=Oracle MAA,
O=Oracle,L=Frankfurt,ST=Frankfurt,C=GE
* start date: Jul 27 15:59:00 2023 GMT
* expire date: Jul 26 15:59:00 2024 GMT
* common name: gghub_prim_vip.frankfurt.goldengate.com
* issuer: OID.2.5.29.19=CA:true,
CN=gghub_prim_vip.frankfurt.goldengate.com,OU=Oracle MAA,O=Oracle,L=Frankfurt,C=EU
* Server auth using Basic with user 'oggadmin'
> GET /services/v2/config/health HTTP/1.1
> Authorization: Basic b2dnYWRtaW46V0VsY29tZTEyM19fXw==
> User-Agent: curl/7.29.0
> Host: gghub_prim_vip.frankfurt.goldengate.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.24.0
< Date: Thu, 27 Jul 2023 16:25:26 GMT
< Content-Type: application/json
< Content-Length: 941
< Connection: keep-alive
< Set-Cookie:
ogg.sca.mS+pRfBERzqE+RTFZPPoVw=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJv
Z2cuc2NhIiwiZXhwIjozNjAwLCJ0eXAiOiJ4LVNDQS1BdXRob3JpemF0aW9uIiwic3ViIjoib2dnYWRta
W4iLCJhdWQiOiJvZ2cuc2NhIiwiaWF0IjoxNjkwNDc1MTI2LCJob3N0IjoiZ2dodWJsYV92aXAubG9uZG
9uLmdvbGRlbmdhdGUuY29tIiwicm9sZSI6IlNlY3VyaXR5IiwiYXV0aFR5cGUiOiJCYXNpYyIsImNyZWQ
iOiJFd3VqV0hOdzlGWDNHai9FN1RYU3A1N1dVRjBheUd4OFpCUTdiZDlKOU9RPSIsInNlcnZlcklEIjoi
ZmFkNWVkN2MtZThlYi00YmE2LTg4Y2EtNmQxYjk3ZjdiMGQ3IiwiZGVwbG95bWVudElEIjoiOTkyZmE5N
DUtZjA0NC00NzNhLTg0ZjktMTRjNTY0ZjNlODU3In0=.knACABXPmZE4BEyux7lZQ5GnrSCCh4x1zBVBL
aX3Flo=; Domain=gghub_prim_vip.frankfurt.goldengate.com; Path=/; HttpOnly; Secure;
SameSite=strict
< Set-Cookie:
ogg.csrf.mS+pRfBERzqE+RTFZPPoVw=1ae439e625798ee02f8f7498438f27c7bad036b270d6bfc9
5aee60fcee111d35ea7e8dc5fb5d61a38d49cac51ca53ed9307f9cbe08fab812181cf163a743bfc7;
Domain=gghub_prim_vip.frankfurt.goldengate.com; Path=/; Secure; SameSite=strict
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Expires: 0
< Pragma: no-cache
< Content-Security-Policy: default-src 'self' 'unsafe-eval'
'unsafe-inline';img-src 'self' data:;frame-ancestors
https://gghub_prim_vip.frankfurt.goldengate.com;child-src
https://gghub_prim_vip.frankfurt.goldengate.com blob:;
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-OGG-Proxy-Version: v1
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
<
* Connection #0 to host gghub_prim_vip.frankfurt.goldengate.com left intact
{"$schema":"api:standardResponse","links":[{"rel":"canonical",
"href":"https://gghub_prim_vip.frankfurt.goldengate.com/services/v2/config/health",
"mediaType":"application/json"},{"rel":"self",
"href":"https://gghub_prim_vip.frankfurt.goldengate.com/services/v2/config/health",
"mediaType":"application/json"},{"rel":"describedby",
"href":"https://gghub_prim_vip.frankfurt.goldengate.com/services/ServiceManager/v2/metadata-catalog/health",
"mediaType":"application/schema+json"}],"messages":[],
"response":{"$schema":"ogg:health","deploymentName":"ServiceManager",
"serviceName":"ServiceManager","started":"2023-07-27T15:39:41.867Z","healthy":true,
"criticalResources":[{"deploymentName":"gghubl1","name":"adminsrvr","type":"service",
"status":"running","healthy":true},{"deploymentName":"gghub1","name":"distsrvr",
"type":"service","status":"running","healthy":true},{"deploymentName":"gghub1",
"name":"recvsrvr","type":"service","status":"running","healthy":true}]}}
*** Success
[root@gghub_prim1 ~]# rm access.cfg
ノート:
自己署名SSL証明書を使用している環境では、curlコマンドにフラグ--insecureを追加することで、エラー"NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)"を回避します。ステップ3.6.8 - NGINX default.conf構成ファイルの削除
すべてのGGHUBでroot
OSユーザーとして、/etc/nginx/conf.d
に作成されているデフォルト構成ファイル(default.conf
)を削除します。
[opc@gghub_prim1 ~]$ sudo rm -f /etc/nginx/conf.d/default.conf
[opc@gghub_prim1 ~]$ sudo nginx -s reload
ステップ3.6.9 - GoldenGate NGINX構成ファイルの配布
GoldenGateサービス・マネージャ用のすべてのリバース・プロキシ構成ファイルを作成した後に、そのファイルを2番目のGoldenGate Hubノードにコピーする必要があります。
最初のGGHUBノードでopc
OSユーザーとして、すべてのデータベース・ノードにNGINX構成ファイルを配布します。
[opc@gghub_prim1 ~]$ sudo tar fczP /tmp/nginx_conf.tar /etc/nginx/conf.d/
/etc/nginx/ssl/
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ scp /tmp/nginx_conf.tar gghub_prim2:/tmp/.
2番目のGGHUBノードでopc
OSユーザーとして、NGINX構成ファイルを展開し、デフォルトの構成ファイルを削除します。
[opc@gghub_prim2 ~]$ sudo tar fxzP /tmp/nginx_conf.tar
[opc@gghub_prim2 ~]$ sudo rm /etc/nginx/conf.d/default.conf
2番目のGGHUBノードでopc
OSユーザーとして、NGINXを再起動します。
[opc@gghub_prim2 ~]$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@gghub_prim2 ~]$ sudo systemctl restart nginx
ノート:
プライマリおよびスタンバイのGGHUBシステムで、セクション3.6のすべてのステップを繰り返します。ステップ3.7 - Oracle GoldenGate Microservicesの保護によるセキュアでない直接アクセスの制限
セキュアでないOracle GoldenGate MicroservicesデプロイメントにNGINXリバース・プロキシを構成していると、そのマイクロサービスは構成したマイクロサービスのポート番号を使用してHTTP (非セキュア)のアクセスができる状態が続きます。たとえば、http://vip-name:9101というセキュアでないURLを使用して管理サーバーにアクセスできます。
Oracle GoldenGate Microservicesの各サーバー(サービス・マネージャ、adminserver、pmsrvr、distsrvrおよびrecsrvr)に対するデフォルトの動作では、構成されたポート番号を使用してすべてのネットワーク・インタフェースでリスニングします。これは、マイクロサービスへのHTTPを使用した直接アクセスを無効にして、NGINX HTTPSを使用したアクセスのみ許可する必要がある、よりセキュアなインストールには望ましくありません。
次のコマンドを使用して、localhostアドレスのみを使用するようにサービス・マネージャとデプロイメント・サービスのリスナー・アドレスを変更します。Oracle GoldenGate Microservicesへのアクセスはlocalhostからのみ許可されるようになり、localhost外部のアクセスはNGINX HTTPSポートを使用してのみ成功するようになります。
ステップ3.7.1 - サービス・マネージャの停止
最初のGGHUBノードでgrid
OSユーザーとして、GoldenGateデプロイメントを停止します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl stop goldengate gghub1
[grid@gghub_prim1 ~]$ agctl status goldengate
Goldengate instance 'gghub1' is not running
ステップ3.7.2 - サービス・マネージャ・リスナー・アドレスの変更
最初のGGHUBノードでoracle
OSユーザーとして、次のコマンドでリスナー・アドレスを変更します。変更するサービス・マネージャに、適切なポート番号を使用してください。
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$ export OGG_HOME=/u01/app/oracle/goldengate/gg21c
[oracle@gghub_prim1 ~]$ export OGG_VAR_HOME=/mnt/acfs_gg1/deployments/ggsm01/var
[oracle@gghub_prim1 ~]$ export OGG_ETC_HOME=/mnt/acfs_gg1/deployments/ggsm01/etc
[oracle@gghub_prim1 ~]$ $OGG_HOME/bin/ServiceManager
--prop=/config/network/serviceListeningPort
--value='{"port":9100,"address":"127.0.0.1"}' --type=array --persist --exit
ステップ3.7.3 - サービス・マネージャとデプロイメントの再起動
最初のGGHUBノードでgrid
OSユーザーとして、GoldenGateデプロイメントを再起動します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl start goldengate gghub1
[grid@gghub_prim1 ~]$ agctl status goldengate
Goldengate instance 'gghub1' is running on exadb-node1
ステップ3.7.4 - GoldenGate Microservicesリスナー・アドレスの変更
最初のGGHUBノードでoracle
OSユーザーとして、次のコマンドを使用して、サービス・マネージャで管理されるデプロイメントのGoldenGateマイクロサービス(adminsrvr、pmsrvr、distsrvr、recvsrvr)のリスニング・アドレスをすべてlocalhostに変更します。
[opc@gghub_prim1 ~]$ sudo chmod g+x /u01/oracle/scripts/secureServices.py
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$ /u01/oracle/scripts/secureServices.py http://localhost:9100
--user oggadmin
Password for 'oggadmin': <oggadmin_password>
*** Securing deployment - gghub1
Current value of "/network/serviceListeningPort" for "gghub1/adminsrvr" is 9101
Setting new value and restarting service.
New value of "/network/serviceListeningPort" for "gghub1/adminsrvr" is
{
"address": "127.0.0.1",
"port": 9101
}.
Current value of "/network/serviceListeningPort" for "gghub1/distsrvr" is 9102
Setting new value and restarting service.
New value of "/network/serviceListeningPort" for "gghub1/distsrvr" is
{
"address": "127.0.0.1",
"port": 9102
}.
Current value of "/network/serviceListeningPort" for "gghub1/pmsrvr" is 9104
Setting new value and restarting service.
New value of "/network/serviceListeningPort" for "gghub1/pmsrvr" is
{
"address": "127.0.0.1",
"port": 9104
}.
Current value of "/network/serviceListeningPort" for "gghub1/recvsrvr" is 9103
Setting new value and restarting service.
New value of "/network/serviceListeningPort" for "gghub1/recvsrvr" is
{
"address": "127.0.0.1",
"port": 9103
}.
ノート:
単一のデプロイメント(adminsrvr、pmsrvr、distsrvr、recvsrvr)を変更する場合は、フラグ--deployment instance_name
を追加しますステップ3.8 - NGINXを管理するClusterwareリソースの作成
Oracle Clusterwareは、NGINXリバース・プロキシの起動を制御して、GoldenGateデプロイメントの起動前に自動的にリバース・プロキシを起動できるようにする必要があります。
最初のGGHUBノードでgrid
OSユーザーとして、次のコマンドを使用して、基盤となるネットワークCRSリソースに依存するNGINXリソースの作成に必要なアプリケーションVIPリソース名を取得します。
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ crsctl stat res -w "TYPE = app.appviptypex2.type" |grep NAME
NAME=gghub_prim_vip
最初のGGHUBノードでroot
OSユーザーとして、次のコマンドを使用して、NGINXを管理するClusterwareリソースを作成します。HOSTING_MEMBERS
値とCARDINALITY
値は、ご使用の環境に合わせて置き換えます。
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# vi /u01/oracle/scripts/add_nginx.sh
# Run as ROOT
$(grep ^crs_home /etc/oracle/olr.loc | cut -d= -f2)/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(<gghub_prim_vip>)
pullup(<gghub_prim_vip>)', STOP_DEPENDENCIES='hard(intermediate:<gghub_prim_vip>)',
RESTART_ATTEMPTS=0, HOSTING_MEMBERS='<gghub_prim1>,<gghub_prim2>', CARDINALITY=2"
[root@gghub_prim1 ~]# sh /u01/oracle/scripts/add_nginx.sh
この例で作成したNGINXリソースは、指定のデータベース・ノード(HOSTING_MEMBERS
で指定)で同時に実行されます。これは、複数のGoldenGateサービス・マネージャのデプロイメントが構成されていて、それらがデータベース・ノード間で独立して移動できる場合にお薦めします。
NGINX Clusterwareリソースの作成後には、GoldenGateデプロイメントの起動前にNGINXを起動するように、GoldenGate XAGリソースを変更する必要があります。
最初のGGHUBノードでroot
OSユーザーとして、次のコマンド例を使用してXAGリソースを変更します。
# Determine the current --file systems parameter:
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl config goldengate gghub1 |grep -i "file system"
File System resources needed: acfs_primary
# Modify the --file systems parameter:
[opc@gghub_prim1 ~]$ sudo su -
[root@gghub_prim1 ~]# /u01/app/grid/xag/bin/agctl modify goldengate gghub1
--filesystems acfs_primary,nginx
[opc@gghub_prim1 ~]$ sudo su - grid
[grid@gghub_prim1 ~]$ agctl config goldengate gghub1 |grep -i "File system"
File System resources needed: acfs_primary,nginx
ノート:
NGINXに依存するXAG GoldenGateの登録ごとに、前述のコマンドを繰り返します。プライマリおよびスタンバイのGGHUBシステムで、セクション3.8のすべてのステップを繰り返します。
ステップ3.9 - Oracle GoldenGateデータベース接続用のOracle Net TNS別名の作成
ノード間の切替え時にOracle GoldenGateプロセスにローカル・データベース接続を提供するために、Oracle GoldenGateが起動される可能性のあるクラスタのすべてのノードに対するTNS別名を作成します。TNS別名は、デプロイメントの作成時に指定したTNS_ADMIN
ディレクトリ内のtnsnames.ora
ファイルで作成します。
ソース・データベースがマルチテナント・データベースの場合は、2つのTNS別名エントリが必要になります。その1つはコンテナ・データベース(CDB)用、もう1つはレプリケートされるプラガブル・データベース(PDB)用です。ターゲットのマルチテナント・データベースでは、TNS別名によってレプリケートしたデータが適用されている場所にPDBを接続します。プラガブル・データベースSERVICE_NAME
を、前のステップで作成したデータベース・サービスに設定する必要があります(「タスク2: GGHubのプライマリおよびスタンバイ・ベース・システムの準備」の「ステップ2.3: データベース・サービスの作成」を参照)。
プライマリおよびスタンバイのデータベース・システムの任意のデータベース・ノードでoracle
OSユーザーとして、dbaascliを使用してデータベース・ドメイン名とSCAN名を検索します。
# Primary DB
[opc@exadb1_node1]$ sudo su - oracle
[oracle@exadb1_node1]$ source db_name.env
[oracle@exadb1_node1]$ dbaascli database getDetails --dbname <db_name>
|grep 'connectString'
"connectString" : "<primary_scan_name>:1521/<service_name>"
# Standby DB
[opc@exadb2_node1]$ sudo su - oracle
[oracle@exadb2_node1]$ source db_name.env
[oracle@exadb2_node1]$ dbaascli database getDetails --dbname <db_name>
|grep 'connectString'
"connectString" : "<standby_scan_name>:1521/<service_name>"
プライマリおよびスタンバイGGHUBのすべてのノードでoracle
OSユーザーとして、sqlnet.ora
ファイルにOracle GoldenGateの推奨パラメータを追加します。
[opc@gghub_prim1]$ sudo su - oracle
[oracle@gghub_prim1]$ mkdir -p /u01/app/oracle/goldengate/network/admin
[oracle@gghub_prim1]$
cat > /u01/app/oracle/goldengate/network/admin/sqlnet.ora <<EOF
DEFAULT_SDU_SIZE = 2097152
EOF
プライマリおよびスタンバイGGHUBのすべてのノードでoracle
OSユーザーとして、ステップに従ってTNS別名の定義を作成します。
[opc@gghub_prim1 ~]$ sudo su - oracle
[oracle@gghub_prim1 ~]$
cat > /u01/app/oracle/goldengate/network/admin/tnsnames.ora <<EOF
# Source
<source_cbd_service_name>=
(DESCRIPTION =
(CONNECT_TIMEOUT=3)(RETRY_COUNT=2)(LOAD_BALANCE=off)(FAILOVER=on)(RECV_TIMEOUT=30)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<primary_scan_name>)(PORT=1521)))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<standby_scan_name>)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = <source_cbd_service_name>.goldengate.com)))
<source_pdb_service_name>=
(DESCRIPTION =
(CONNECT_TIMEOUT=3)(RETRY_COUNT=2)(LOAD_BALANCE=off)(FAILOVER=on)(RECV_TIMEOUT=30)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<primary_scan_name>)(PORT=1521)))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<standby_scan_name>)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = <source_pdb_service_name>.goldengate.com)))
# Target
<target_pdb_service_name>=
(DESCRIPTION =
(CONNECT_TIMEOUT=3)(RETRY_COUNT=2)(LOAD_BALANCE=off)(FAILOVER=on)(RECV_TIMEOUT=30)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<primary_scan_name>)(PORT=1521)))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=<standby_scan_name>)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = <target_pdb_service_name>.goldengate.com)))
EOF
[oracle@gghub_prim1 ~]$ scp /u01/app/oracle/goldengate/network/admin/*.ora
gghub_prim2:/u01/app/oracle/goldengate/network/admin
ノート:
Oracle GoldenGateデプロイメントのTNS_ADMIN
ディレクトリにあるtnsnames.ora
またはsqlnet.ora
を変更した場合は、変更内容を採用するためにデプロイメントを再起動する必要があります。