1. Oracle Internet Directoryの管理
  2. 付録
  3. レプリケーションの動作

A.3 レプリケーションの動作

この付録では、レプリケーションの動作について説明し、LDAPベースのレプリケーションの機能とアーキテクチャ、LDAPのレプリカ状態およびレプリケーション・プロセスについて説明します。

この付録の内容は次のとおりです。

ノート:

この付録で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g (10.1.4.3.0)以上のことです。

A.3.1 LDAPベースのレプリケーションのアーキテクチャ

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降では、LDAPレプリケーションのデータフローは適用キューを含む適用フェーズから構成されます。トランスポート・キューを含むトランスポート・フェーズは使用されなくなりました。この項では、LDAPレプリケーションの詳細を説明します。

図A-2およびその後に続く説明で、ファンアウト・レプリケーション・プロセスを示します。

図A-2 LDAPレプリケーション・プロセス

テキストで説明します

  1. LDAP変更リクエストが、レプリカAのOracle Internet Directoryサーバーで作成されます。

  2. 変更は、受け入れられ、Oracle Internet Directoryデータベースのストレージにコミットされます。

  3. この操作に対して新規の変更ログが生成され、ods_chg_log表に格納されます。

    • server = レプリカA

    • orclreplicationid/chg_rid = 0 (値0はユーザー操作用です。)

    • Modifiersname = 修飾子のユーザー識別名(デフォルト)

  4. レプリカBのレプリケーション・サーバーは、レプリカAのods_chg_log表から変更ログをフェッチし、メモリー内で部分的なレプリケーション・フィルタリングをいくつか実行した後、適用キューに直接変更ログを格納します。orclupdateschedule構成属性は、レプリケーションの頻度を決定します。

  5. レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryサーバーに変更をストレージにコミットするようにリクエストします。

  6. レプリカBのOracle Internet Directoryサーバーは、Oracle Internet Directoryデータベース記憶域に変更をコミットし、asr_chg_log表に変更をコピーし、再試行回数を-2に更新します。これらはすべて、単一のLDAPコールで実行されます。

    コミット時に失敗が生じた場合、Oracle Internet Directoryサーバーはレプリケーション・サーバーにエラーをレポートし、asr_chg_log表に変更をコピーし、再試行回数を1ずつ減少させます。この場合、Oracle Internet Directoryサーバーはコミットを再適用できます。

    すべての変更ログは、成否にかかわらず、レプリカBのasr_chg_log表にコピーされます。

  7. レプリカBがその他のレプリカのソースである場合、レプリカBのods_chg_log表に変更ログが、次のchangelog再生成規則に従って再生成されます。

    • server = ローカル・レプリカ、レプリカBのサーバー

    • orclreplicationid/chg_rid = N

    • Modifiersname = Replbind_DN_of_A

    orclreplicatid/chg_ridは、処理承諾のorclreplicationid値に設定されます。

A.3.2 LDAPのレプリカ状態

LDAPベースのレプリケーションのレプリカ状態について説明します。

LDAPベースのレプリケーションを構成し、レプリケーション・サーバーを起動すると、サーバーはローカルのレプリカ(orclreplicaid=local_Replica_ID, cn=replication configuration)からレプリカ状態orclreplicastateを読み取ります。表A-2に示すとおり、レプリケーション・サーバーの動作はローカルのレプリカ状態によって異なります。レプリケーション・サーバーは、ローカル(コンシューマ)・ノードからローカルのレプリカ状態を読み取ります。

ノート:

WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。

表A-2 LDAPのレプリカ状態

値 意味 サーバーの動作

0

ブートストラップ

レプリケーションのネーミング・コンテキスト構成に基づき、サプライヤからコンシューマ・ディレクトリを同期化するためのレプリケーションのブートストラップ・プロセスを開始する。ブートストラップの進行に合せてレプリカ状態を更新する。

  • ブートストラップの開始直後は、レプリカ状態を3(ブートストラップ進行中)にする。

  • cn=oraclecontextのブートストラップが正常に完了すると、レプリカ状態を4(ブートストラップ進行中、cn=oraclecontextのブートストラップが完了)にする。

  • ブートストラップが完了したが、ブートストラップ中に障害が検出された場合は、レプリカ状態を5(ブートストラップ・エラーの発生)にする。次に、レプリカ状態がリセットされるまで待機する。

    ノート: 管理者操作が必要。詳細は「Oracle Internet Directoryレプリケーションに関するトラブルシューティング」を参照。

  • ブートストラップが正常に完了すると、レプリカ状態を1(オンライン)にする。次に、レプリケーションを自動的に開始し、通常のレプリケーション・プロセスを実行する。

1

オンライン

通常のレプリケーション・プロセスを開始し、サプライヤからコンシューマへ変更をレプリケートする。

2

オフライン

エラー・メッセージを、次のようにoidrepld.logに記録する。

2004/09/24:17:41:44 * Replica(dlsun1418_replica2) is in
OFFLINE mode, Please update the replica state and restart
OIDREPLD...

管理者は、レプリカ状態を適切に設定し、レプリケーション・サーバーを再起動する必要がある。

3

ブートストラップ進行中

レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。

4

ブートストラップ進行中、cn=oraclecontextのブートストラップが完了。

レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。

5

ブートストラップの完了。1つ以上のネーミング・コンテキストで障害を検出。

エラー・メッセージを、次のようにoidrepld.logに記録する。

2004/09/24:17:13:30 * Replication BOOTSTRAP_ERROR mode detected for replica(dlsun1418_replica2)

次に、レプリカ状態が適切にリセットされるまで待機する。

6

データベース・コピー・ベースのaddnode。

このモードは、レプリカがデータベース・コピー・ベースのaddnodeであることを示す。

7

スキーマの同期化

サプライヤからコンシューマへの、データではなくスキーマの同期化。

8

スキーマを同期化しないブートストラップ

以前にスキーマの同期化が実行されているものの、後続のステップでブートストラップが失敗している場合には、スキーマの同期化を再実行せずに再度ブートストラップが開始される。

Oracle Internet Directoryレプリケーション・サーバーでは、Oracle Internet Directoryレプリケーション・サーバー・ログ($DOMAIN_HOME/servers/OID/logs/componentName/oidrepld00.log)にブートストラップ・プロセスが記録されます。

ブートストラップが正常に完了した場合、ログは次の例と同様になり、レプリケーション・サーバーが自動的に通常のレプリケーション・プロセスを開始します。

2004/10/06:17:13:25 * Starting OIDREPLD against isunnad03:5555...
2004/10/06:17:13:26 * Starting scheduler...
2004/10/06:17:13:27 * Start to BootStrap from supplier=isunnad03_purify to consumer=isunnad03_purify3
2004/10/06:17:13:28 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=india ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: c=india, 0 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=uk ......
2004/10/06:17:19:57 * gslrbssSyncDIT:Sync done successfully for namingctx: c=uk, 1087 entries matched
2004/10/06:17:19:57 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/10/06:17:19:59 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/10/06:17:20:01 * gslrbsbBootStrap: BOOTSTRAP DONE SUCCESSFULL

障害が検出された場合、ログは次の例と同様になります。

2004/09/14:12:57:23 * Starting OIDREPLD against dlsun1418:4444...
2004/09/14:12:57:25 * Starting scheduler...
2004/09/14:12:57:26 * Start to BootStrap from supplier=dlsun1418_replica to consumer=dlsun1418_replica2
2004/09/14:12:57:27 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/09/14:12:58:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/09/14:12:58:21 * gslrbssSyncDIT:Replicating namingcontext=cn=quan zhou ......
2004/09/14:12:58:23 * BootStrap failure when adding DN=cn=Quan Zhou,server=dlsun1418_replica2,err=Constraint violation.
2004/09/14:12:58:23 * gslrbssSyncDIT:Sync failed for namingctx: cn=quan zhou, only 1 entries retrieved
2004/09/14:12:58:23 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/09/14:12:58:25 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/09/14:12:58:51 * gslrbsbBootStrap: Failure occurred when bootstrapping 1 out of 3 namingcontext(s) from the supplier

ヒント:

ブートストラップの障害のトラブルシューティングには2つのオプションがあります。

  • オプション1: ブートストラップの障害の原因を特定し、修正します。次に、コンシューマ・レプリカのorclreplicastateをブートストラップ・モードにして、ブートストラップを再起動します。

  • オプション2: ブートストラップに失敗したネーミング・コンテキストを特定し、oidcmprecを使用してこれらを調整します。次に、コンシューマ・レプリカのorclreplicastateをオンライン・モードにして、レプリケーションを再開します。

ノート:

このとき、OidrepldはBootstrap_errorモードになっているので、コンシューマ・レプリカのレプリカ状態(orclreplicastate)をリセットする必要があります。

A.3.3 マルチマスター・レプリケーション・プロセスを使用したエントリの管理

この項では、マルチマスター・レプリケーション・プロセスによるエントリの追加、削除、変更方法、および識別名と相対識別名の変更方法について紹介します。この項の内容は、次のとおりです。

A.3.3.1 マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマに新規エントリを追加すると、次の変更適用プロセスを実行します。

  1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内でターゲット・エントリの親の識別名を探します。具体的には、その親の識別名に割り当てられているGlobal Unique Identifier(GUID)を探します。

  2. 親エントリが存在している場合、ディレクトリ・レプリケーション・サーバーは新規エントリの識別名を作成し、コンシューマ内にあるその親の下に新規エントリを配置します。次に、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは新しい変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、新規エントリが既存エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

  • 作成タイムスタンプが古い方のエントリを使用します。

  • 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて変更が適用され、その変更エントリがパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、orclHIQScheduleパラメータで指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更を保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

A.3.3.2 マルチマスター・レプリケーション・プロセスがエントリを削除する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマからエントリを削除すると、次の変更適用プロセスを実行します。

  1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。

  2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリを削除します。次に、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

A.3.3.3 マルチマスター・レプリケーション・プロセスがエントリを変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリを変更すると、次の変更適用プロセスを実行します。

  1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。

  2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーは、変更エントリ内の各属性と、ターゲット・エントリ内の各属性を比較します。

  3. その後、ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

    1. 変更時間が最新の属性を使用します。

    2. 最新バージョンの属性を使用します(バージョン1、2または3など)。

    3. ホスト上の変更された属性のうち、アルファベットのAに最も近い名前のエントリを使用します。

  4. ディレクトリ・レプリケーション・サーバーは、フィルタ処理済の変更を適用し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった 場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

A.3.3.4 マルチマスター・レプリケーション・プロセスが相対識別名を変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの相対識別名を変更すると、次の変更適用プロセスを実行します。

  1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。

  2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの相対識別名を変更し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

  • 作成タイムスタンプが古い方のエントリを使用します。

  • 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

A.3.3.5 マルチマスター・レプリケーション・プロセスが識別名を変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの識別名を変更すると、次の変更適用プロセスを実行します。

  1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。

    また、ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリに指定されている新しい親のGUIDと一致するGUIDを持つ親の識別名も探します。

  2. ターゲット・エントリの識別名と親の識別名の両方がコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの識別名を変更し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった 場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

  • 作成タイムスタンプが古い方のエントリを使用します。

  • 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。