1. Introduction

1.1 双方向レプリケーション

前回まででGoldenGate を使用した片方向のレプリケーションについての検証を行いました。今回は少し複雑な設定が必要となりますが、(単に双方向のレプリケーションを行うだけであれば、設定は簡単です。) 双方向レプリケーションについて解説を行います。GoldenGate は片方向レプリケーションでも双方向レプリケーションでもライセンス費用は変わりませんが、GoldenGate が行っている双方向レプリケーション相当の事をOracle Database 単体で行おうとすると、Enterprise Edition の機能 (Advanced Replication) が必要となります。GoldenGate を使用すると、Standard Edition のDatabase (Standard Edition Oneでも可能) を使用して双方向レプリケーション環境する事が構築できるので、ある意味お得です。それでは実際に双方向レプリケーションの環境を構築してみましょう。

1.2 GoldenGate による双方向レプリケーション

GodenGate では、以下の図のように旧環境/新環境の双方にCapture/DataPump/Replicat を実装する事で双方向レプリケーションの構成を組む事ができます。双方向レプリケーションの構成を組む事によって、新環境側で行ったDB 変更を旧環境側に反映させる事ができるため、移行後のシステムに万一問題が発生した際に最新の状態で旧環境に切戻しを行う事が可能になります。設定内容の差異は、新環境から旧環境にレプリケートする際に使用するトレイル・ファイル名を旧環境から新環境へのレプリケート時に使用している名前と重複しないように指定するだけです。設定内容は基本的にこれまでに説明してきた片方向レプリケーションの構成をもう1セット設定するだけですが、データ同期が双方向になった事による注意事項がありますので、双方向レプリケーション構成時の注意事項について重点的に説明します。

※説明を簡略化するために、DDL／データ変換を含むレプリケーションは行わないものとします。

1.2.1 GoldenGate による更新データの再Capture防止

GoldenGate (Replicat) による更新もRedo Log に記録されますが、この更新ログをCaptureされるとDB更新が 無限ループ陥ってしまうためGoldenGate による更新は再Capture の対象外とする必要があります。GoldenGate ではOracle Database の場合、ユーザ名/ユーザID によりフィルタリングする事が可能となっており、GoldenGate 管理ユーザ(今回はGGS) による更新をCapture の対象外とする事でDB 更新が無限ループに陥るのを防止する事が可能です。GGS ユーザによる更新を、Capture の対象外とするには、Capture プロセスのパラメータ・ファイルに、以下の行を追加してCapture プロセスを再起動します。

・TRANLOGOPTIONS EXCLUDEUSER ggs

ここではGoldenGate 管理ユーザを指定していますが、他の業務アプリケーションのユーザを指定する事も可能です。
各プロセスのパラメータ・ファイルを以下に示します。

旧環境

1) Capture プロセス

2) DataPump プロセス

3) Replicat プロセス

新環境

1) Capture プロセス

2) DataPump プロセス

3) Replicat プロセス

1.2.2 動作確認

それでは、旧環境/新環境からSQL*Plus を使用して双方向レプリケーションの確認を実施します。

1.2.3　競合の解決

GoldenGate は短い間隔でデータ同期を行っているため、競合が発生する可能性は低いものの、双方のDB が更新可能であるためReplicat が更新データの反映を行った際に、競合が発生して以下の状態が発生する可能性があります。

1. 一意性競合 (同じキー値を持つデータの同時Insert)
2. 更新競合 (同じレコードを同時に更新)
3. 削除競合 (他DB で削除されたレコードの更新)

双方向レプリケーションでは、上記のような状態になった時にどのようなデータを正とするか (競合解決のルールを) 事前に決めておく必要があります。 競合を解決するためには、以下の手順を実行します。

1. ビフォア・イメージのロギング有効化
2. 例外表の作成 (オプション)
3. 競合解決のためのGoldenGate パラメータ・ファイルの構成

それでは上記の手順について、具体的に説明していきます。

1) ビフォア・イメージのロギング有効化

競合解決を行うためには、Supplemental Logging に更新行のビフォア・イメージを含める必要があります。以下に、手順を示します。

2) 例外表の作成 (オプション)

GoldenGate にはReplicat で競合を検出した際に解析を容易にするため、競合したレコードを例外表に記録する仕組みがあります。
今回も例外表を作成して、競合データの分析を行えるようにします。
今回はscott.emp 表を使用しているので、同じ構成で例外表を作成します。

3) 競合解決のためのGoldenGate パラメータ・ファイルの構成

Supplemental Logging にビフォア・イメージを含める設定が完了したら、Capture, DataPump のパラメータ・ファイルでビフォア・イメージを取得するよう設定を行い、該当プロセスを再起動します。
各プロセスのパラメータ・ファイルを以下に示します。

1)Capture プロセス

パラメータの説明

2) DataPump プロセス


注意 : GETBEFORECOLS パラメータは、PASSTHRU との併用は不可

修正したパラメータはCapture プロセスと同じため、詳細は省略します。

3) Replicat プロセス


注意 : & はパラメータを複数行に分けて記述する際の継続文字です。

【競合解消ルールの説明】
・更新競合が検出された場合は、SAL 列の値の大きい方を正とする。
・更新レコードが削除されていた場合は、Insert に変換して適用する。
・削除レコードのビフォア・イメージが異なる場合は、無視する。

パラメータの説明

1.2.4　動作確認

SQL*Plus から競合を発生させて、結果を確認します。

以上でGoldenGate 双方向レプリケーションによる競合検出／解消を確認する事ができました。
後は今までの構成を組み合わせる事で、他の構成も構築する事が可能となります。