ヘッダーをスキップ
Oracle Fusion Middleware Oracle Internet Directory管理者ガイド
11g リリース1(11.1.1)
B55919-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

D レプリケーションの動作

この付録では、レプリケーションに関する詳細情報について説明します。この付録には、次の項があります。


注意:

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

D.1 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの機能

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでは、レプリケーション承諾がなされたOracle Internet Directoryノード間における更新情報の転送は、Oracle Databaseアドバンスト・レプリケーションのストア/フォワード転送機能によって管理されます。アドバンスト・レプリケーションを使用すると、2つのOracleデータベース間で、データベース表を同期化させることができます。

Oracle Databaseアドバンスト・レプリケーション:

D.2 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションのアーキテクチャ

一般的なOracle Databaseアドバンスト・レプリケーション構成では、サプライヤが変更内容を変更ログに書き込み、バッチ処理された変更を他のコンシューマに定期的に送信する非同期データ伝播を使用します。コンシューマは変更ログ・データを受信し、変更内容をローカルに適用します。

レプリケーションを構成する場合は、レプリケーション・グループ内で変更を共有するノードを指定します。レプリケーション環境に導入するノードの数にかかわらず、レプリケーションの基本アーキテクチャは同一です。ローカル変更がリモート・マスター・サイトに配布されると、クライアントとして機能するレプリケーション・サーバーによってOracle Internet Directoryサーバーにコマンドが送信され、ここでコマンドが実装されます。

図D-1とその後に続く説明では、Oracle Databaseアドバンスト・レプリケーション・プロセスの概要を示します。

図D-1 アドバンスト・レプリケーション・プロセス

この図はテキストで説明します。

プロセスは次のとおりです。

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

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

    2' この操作に対して新規の変更ログが生成され、ods_chg_log表(server = レプリカA)に格納されます。

  3. レプリカA上のレプリケーション・サーバーは、ローカルのods_chg_log表に新規のアウトバウンド変更ログを問い合せます。この問合せには次のフィルタが使用されます。

    (& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) 
         (changeNumber>= Last_Applied_ChgNum_From_A_TO_A) )
    

    この検索操作とともに、処理承諾で指定されたorclreplicationidの値で制御も渡されます。値1は、アドバンスト・レプリケーション承諾のために予約されています。

    Last_Applied_ChgNum_From_A_TO_Aは、アウトバウンド変更ログ処理ステータスです。

    3' ディレクトリ・サーバーは、ods_chg_logに新規の変更ログを内部的に問い合せて、フェッチした変更ログを返します。

  4. ods_chg_logから取得した新規の変更ログは、ローカルのasr_chg_logにコピーされます。

    4' レプリケーション・サーバーは、取得した変更ログをローカルのasr_chg_logにコピーします。

  5. レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、変更ログretry_cntのステータスを正しく更新するようにリクエストします。

    5' Oracle Internet Directoryサーバーは、ods_chg_log表にある変更ログのretry_cntを更新します。

  6. 新規の変更ログは、Oracle Databaseアドバンスト・レプリケーションを介して、レプリカAからレプリカBに送信されます。

  7. レプリカBにおいて、前回移送された数が前回適用された変更の数より大きい場合は、ローカル変更ログ・ストアasr_chg_logに新規の変更があることを示しています。この場合、レプリカB上のレプリケーション・サーバーは、ローカルのasr_chg_log表に新規のインバウンド変更ログを問い合せます。次のフィルタが使用されます。

    (& (objectclass=changeLogEntry) (servername=ReplicaID_of_A)
           (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
    

    7' ディレクトリ・サーバーは、asr_chg_logに新規の変更ログを問い合せます。

  8. レプリケーション・サーバーは、レプリカBで新規の変更を適用します。

  9. レプリカBのOracle Internet Directoryサーバーは、変更を受け入れ、Oracle Databaseのストレージにコミットします。

    9' ローカル・レプリカにLDAPベースのコンシューマ・レプリカがある場合、変更ログがレプリカBにあるods_chg_log表で、次の規則に従って再生成されます。

    server = server of local replica,
    ReplicaB orclreplicationid/chg_rid = 1 
    Modifiersname = Replbind_DN_of_A
    

    orclreplicatid/chg_ridは、処理承諾のorclreplicationidの値に設定されます。この場合、変更がアドバンスト・レプリケーションを介してレプリケートと処理が行われるため、値はアドバンスト・レプリケーション用に予約されている1に設定されます。

  10. レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、シャドウ変更ログretry_cntのステータスを正しく更新するようにリクエストします。

    10' Oracle Internet Directoryサーバーは、データベースにあるシャドウ変更ログのretry_cntを更新します。

適用済のエントリや候補の変更に従って削除されたエントリのパージが定期的に発生します。ローカルの変更ログ表にあるリモート変更の記録は、その変更がローカルで適用されると、ガベージ・コレクション・スレッドによってパージされます。ローカルの変更ログ表にあるローカル変更の記録は、その変更がすべてのコンシューマに配布されると、ガベージ・コレクション・スレッドによってパージされます。


関連項目:

レプリケーションの構成方法は、第41章「レプリケーションの管理および監視」を参照してください。

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

この項では、LDAPレプリケーションの詳細を説明します。LDAPレプリケーションでのデータ・フローは、転送と適用の2つのフェーズで構成されます。

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

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

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

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

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

    server = レプリカA

    orclreplicationid/chg_rid = 0(値0はユーザー操作)

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

  3. レプリカB上のレプリケーション・サーバーは、サプライヤのレプリカ、レプリカAのods_chg_log表に新規のインバウンド変更ログを問い合せます。この問合せには次のフィルタが使用されます。

    (& (objectclass=changelogentry) 
    (changeNumber>=Last_Transported_ChgNum_From_A_TO_B)  
    (! (modifiersname=ReplicaID_of_B))
    (! (orclreplicatonid = 
      Orclreplicationid_Attribute_Value_of_Processing_Agreement))
    (!(targetdn=*,excluded_naming_ctx_dn ) (….) (….) ….)
    (targetdn=cn=catalogs) (targetdn=cn=subschemasubentry)
    (targetdn=cn=oracleschemaversion) (targetdn=*,included_naming_ctx_dn)
    (targetdn=….)
    …)
    

    この検索操作とともに、処理承諾で指定されたorclreplicationidの値で制御も渡されます。

  4. レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryに新規の変更ログをシャドウ変更ログとして格納するようにリクエストします。

    4'.レプリカBのOracle Internet Directoryサーバーは、レプリカBのasr_chg_log表にシャドウ変更ログを格納します。

    手順3、3'および4は、LDAPベース変更ログ処理の転送部分と一致します。

  5. レプリカBのレプリケーション・サーバーは、レプリカBにおいて、前回移送された数が前回適用された変更の数より大きいかどうかをチェックします。そうである場合は、ローカル変更ログ・ストアasr_chg_logに新規の変更があることを示しています。この場合、レプリカBのレプリケーション・サーバーは、ローカル・ストアasr_chg_logにAからの新規変更ログを問い合せます。この問合せには次のフィルタが使用されます。

    (& (objectclass=changeLogEntry) (servername=ReplicaID_of_A)
      (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
    
  6. レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryサーバーに取得した変更をストレージに適用するようにリクエストします。

  7. レプリカBのOracle Internet Directoryサーバーは、変更を受け入れ、Oracle Internet Directoryデータベースのストレージにコミットします。

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

    server = server of local replica, ReplicaB
    orclreplicationid/chg_rid = N
    Modifiersname = Replbind_DN_of_A
    

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

  8. レプリケーション・サーバーは、サーバーに対して、シャドウ変更ログretry_cntのステータスを正しく更新するようにリクエストします。

D.4 LDAPのレプリカ状態

この項では、LDAPベースのレプリケーションのレプリカ状態について説明します。LDAPのレプリカ状態は、アドバンスト・レプリケーションには影響しません。

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


注意:

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

表D-1 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レプリケーション・サーバー・ログ($ORACLE_INSTANCE/diagnostics/logs/OID/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)をリセットする必要があります。

D.5 レプリケーション・プロセス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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