自動CDRによるアクティブ/アクティブ・レプリケーションの簡素化

※ 本記事は、Volker Kuhrによる”Simplify Active-Active Replication with Auto-CDR“を翻訳したものです。

アクティブ/アクティブ環境では、Oracle Databasesがレプリケーション環境に自動競合および検出解決(Auto-CDR)を適用することがベスト・プラクティスです。自動CDRでは、競合を検出するだけでなく、次のいずれかの解決方法を適用して競合を解決します:

• 主キーがある表の最新タイムスタンプ解決 ^(12gR2)
• 列グループ ^(12gR2)
• 一意キーを持つ表の自動CDR ^(18c)
• 最初のタイムスタンプ解決 ^(21c)
• 常にwinを削除 ^(21c)
• サイト優先度解決 ^(21c)

例として、データベースDB01とDB02の間に双方向環境を使用します。ここで、最新のタイムスタンプ自動CDRソリューションを追加します。Oracle GoldenGateがこの自動CDRソリューションをどのように提供するかは非常に簡単です。コントリビューションするすべてのデータベースの各表に対する単一のPL/SQLコールです。参加している各Oracle Database (DB01およびDB02)で、対象の表に対して1つのプロシージャを実行するだけです:

SQL> exec DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(‘HR’,’EMPLOYEES’)
Extract/Replicatパラメータ・ファイル[1]内で構成を変更する必要がないため、自動CDRソリューションは、手動の競合検出および解決(CDR)よりもはるかに簡単で、エラーの発生も少なくなります。アーキテクチャおよびユース・ケースによっては、システムに適用できる自動CDRの解像度が異なる場合があります。

• ターゲット・システムでの追加の変更を伴う単方向レプリケーション。
  あるサイト(ソース)から行われた変更は別のサイド(ターゲット)にレプリケートされ、ターゲット・システム自体はレプリケートされたデータに対して変更を実行します。例として、本番システムからテスト・システムでデータが変更されるテスト環境にデータをレプリケーションする場合、本番環境が真のソースであるため、サイトの優先度解決が適切な選択になる場合があります。
• 双方向レプリケーション
  第1サイトからの変更は第2サイトに複製され、他のサイトからの変更は第1サイトに複製されます。ほとんどの場合、最新タイムスタンプ解決は、一貫性のあるデータをすべての場所で保証するために使用されます。
• N方向レプリケーション
  ピア・ツー・ピア、ハブ・アンド・スポーク、拡張/カスケード・システム、またはすべての組合せでデータベースを編成できるため、3つ以上のサイト(N方向レプリケーション)があるレプリケーション環境はさらに複雑になります。

次の図は、自動CDRのコンテキストを詳細に説明し、競合検出と競合解決の2つの主要コンポーネントの詳細を示しています。

競合検出
変更の前イメージがターゲット・システムの現在のイメージと一致しない場合、競合が識別されます。

この場合、変更の前イメージの電話番号が、ターゲットの現在の電話番号と一致しません。

競合解決
システムのグローバルなデータ整合性は、競合解決方法を使用して再構築できます。使用可能な解決方法は複数あります。この例では、最新のタイムスタンプ解決方法を使用します: 各データベースでは、最新のタイムスタンプを持つレコードが適用され、以前のタイムスタンプを持つレコードは無視されます。処理後、データはグローバルに一貫性があります。

パフォーマンスについて: (自動) CDRを使用した基本的なレプリケーションに加えて追加のロジックがあるため、追加のオーバーヘッドが発生します。一般に、共有データを含むテーブルへの同時アクセスを持つシステム内のデータベースの数を制限することによって、競合の可能性を回避するようにしてください。一連の共有データの更新が許可されるのは1つのデータベースのみであるため、プライマリ所有権によって競合が回避されます。これが不可能な場合、Oracle GoldenGateで競合検出および解決方法によってこの問題が解決されます。

自動CDRを使用するための唯一の要件は、Replicatが統合フレーバ(統合モードのパラレルReplicatまたは統合Replicat)にあり、表に主キーまたは少なくとも一意索引が含まれている必要があることです。デフォルトでは、ADD_AUTO_CDRプロシージャは最新のタイムスタンプ競合解決メソッドを使用します。この手順には、簡単に説明したい追加のパラメータも含まれています。表がAUTO_CDRによって管理されているかどうかを識別するには、DBA_GG_AUTO_CDR_TABLESディクショナリ・ビューを問い合せます。

前述のように、対象となるすべてのデータベースでスキーマおよび表名で定義されたベース・オブジェクトのみに対処する必要があります。自動CDRソリューションに複数の表を追加する場合は、対象となる一連の表を‘looping’ することでこれを実行できます。また、パラメータrecord_conflictを使用してWIN/LOSSモニタリング・オプションも有効にします。

BEGIN
  FOR REC in (SELECT owner, table_name FROM dba_tables WHERE owner = ‘HR’) LOOP 
     DBMS_GOLDEMGATE_ADM.ADD_AUTO_CDR(REC.owner,REC.table_name, record_conflicts =>TRUE);
  END LOOP;
END;
/

このプロシージャをコールすると、Extract (ソース)サイトのすべての列でサプリメンタル・ロギングが有効になっているため、ソース・サイトが準備されます。また、Replicat (ターゲット)サイトで競合検出ロジックおよび競合解決方法を内部的に実装します。このCDRメソッドは、データベース内で完全に維持されます。GoldenGateには、追加の構成ステップは必要ありません。したがって、Auto-CDRという名前になります。

ターゲットとしてのデータベースでは、最新TIMESTAMPメソッドがデフォルトで有効になります。ExtractまたはReplicatパラメータ・ファイル内では、追加の構成ステップは必要ありません。名前が示すように、LATEST TIMESTAMP競合解決は、競合するレコードの最新の変更のみが処理されるように機能します:

• 最新のタイムスタンプを持つレコードが適用されます(WIN)。
• タイムスタンプが最も早いレコードは無視されます(LOST)

I双方向環境では、パラメータrecord_conflicts => TRUEを使用してWIN/LOSSの状況を追跡します。競合監視を有効にする場合、DBA_APPLIED_ERROR_MESSAGESディクショナリ・ビューでのWIN/LOSSが表示されます。
DB01:

DB02:


ADD_AUTO_CDRプロシージャには、さらに多くのオプションがあります。詳細は、『PL/SQLリファレンス・ガイド』を参照してください。
バックグラウンドで、自動CDRがベース・オブジェクトとどのように連携するかを理解することは興味深いです。自動CDRでは、非表示のタイムスタンプ(CDRTS$ROW)列が追加されると、実表が変更されます。列が非表示になっているため、この列は見えないため、データベース・アプリケーションには影響しません:

ただし、GoldenGateは、この列を認識し、使用します。このレコードに対するINSERT操作またはUPDATE操作が発生するたびに、この列にタイムスタンプ(UTCタイムゾーン)が内部的に移入されます。手動CDRと比較すると、タイムスタンプ関連の列が不要なため、これは大きな利点となります。タイムスタンプ情報を使用して、非表示列の横に、自動CDRによって各実表の追加表も作成されます。このtombstone表には、主キーの列とタイムスタンプ列が含まれます:

このtombstone表は、DELETEの競合に使用されます: DELETE操作が発生するたびに、実表内のレコードが削除されますが、このレコードに必要な情報がtombstone表に挿入されます。DELETE操作が反対側のサイトからのUPDATE操作より前に行われる場合、UPDATEはINSERTに変換されます。サプリメンタル・ロギングが全表に対して有効になっており、すべてのサプリメンタル・ログ列はデフォルトで証跡ファイルの一部であるため、データベースにレコードを挿入するために必要なすべての情報を使用できます。アプリケーションでDELETE操作が実行されない場合は、tombstone表は不要です。この場合、パラメータtombstone_deletes => FALSEを使用できます。

この記事でわかるように、競合検出および解決の高度なロジックは、GoldenGateの観点から実装が容易になるように、データベース内で完全に維持されます。手動構成の古い方法と比較すると、複雑なExtractファイルおよびReplicatファイルが原因になります。パフォーマンスの観点からは、競合検出解決を使用するソリューションでは、特定のチェックおよびアクションが実行されると追加のオーバーヘッドが発生します。ただし、CDR操作のメンテナンスは内部的に管理されるため、他のソリューションと比較してオーバーヘッドは非常に低くなります。