1. Oracle Internet Directoryの管理
  2. 拡張管理: ディレクトリ・レプリケーション
  3. レプリケーション構成属性の管理

42 レプリケーション構成属性の管理

次のトピックでは、Oracle Internet Directoryレプリケーション・サーバーを制御する構成属性について説明し、LDAPコマンド行ユーティリティを使用してそれらの属性を管理する方法について説明します。

具体的なレプリケーション管理タスクは、「レプリケーションの管理およびモニタリング」を参照してください。

42.1 レプリケーション構成属性の理解

次のトピックでは、DIT内の特定のコンテナに存在する構成属性のコンテキストについて説明します。

42.1.1 レプリケーション構成コンテナ

ノードに関するすべてのレプリケーション情報は、ルートDSEにあるコンテナcn=replication configuration内に存在します。このエントリは、DRG内の各ノードに存在します。

次に、レプリケーション構成コンテナ・エントリの例を示します。

dn: cn=replication configuration
orclaci: access to entry by * (browse)
orclaci: access to attr=(*) by * (search,read)
orclnormdn: cn=replication configuration
cn: replication configuration
description: Replication agreement Container object
objectclass: top
objectclass: orclcontainerOC

42.1.2 レプリカ・サブエントリの理解

次のトピックでは、レプリカ・サブエントリとその属性のコンテキストについて説明します。

42.1.2.1 レプリカ・サブエントリについて

レプリカ・サブエントリには、次の識別名があります

orclreplicaid=Replica_ID,cn=replication configuration

このサブエントリは、インストール時にレプリケーション構成コンテナの下に作成されます。これには、表すノードの特性を識別し、定義する属性が含まれます。

42.1.2.2 レプリカ・サブエントリの属性

表42-1に、レプリカ・サブエントリの属性を示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

表42-1 レプリカ・サブエントリの属性

属性 説明 更新メカニズム デフォルト 使用可能な値

orclreplicaid

ディレクトリ・データベースの一意の識別子。インストール時に初期化されます。ルートDSEのorclreplicaidと一致します。

読取り専用

hostname_ORACLESID

整数

orclreplicauri

このレプリカに接続する際に使用されるアドレス。

LDAP

有効なldapURI書式

orclreplicasecondaryuri

orclReplicaURIを使用できない場合に使用されるアドレス。

LDAP

有効なldapURI書式

orclreplicatype

読取り専用、読取り/書込みなどのレプリカのタイプを定義します。

LDAP

0 (読取り/書込み)

0: 読取り/書込み

1: 読取り専用

2: パイロット

orclpilotmode

レプリカをパイロット(テスト)・モードにするかどうかを定義します。

remtool -pilotreplica

0

0: False

1: True

orclreplicastate

レプリカの状態を定義します。

LDAP

0、1、2、6または8を設定できます。サーバーは他の値を設定します。表A-2を参照してください。

pilotstarttime

レプリカがパイロット(テスト)・モードに切り替わった時刻。

読取り専用

時間

ノート:

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

42.1.2.3 レプリカ・サブエントリの例

図42-3では、レプリカ・サブエントリはorclReplicaID=UID_of_node_D,cn=replication configurationで表されています。

次に、レプリカ・サブエントリの例を示します。

dn: orclreplicaid=myhost1_repl1,cn=replication configuration
objectclass: top
objectclass: orclreplicasubentry
orclreplicaid: myhost1_repl1
orclreplicauri: ldap://myhost1:3060/
orclreplicasecondaryuri: ldap://myhost1.mycompany.com:3060/
orclreplicastate: 1

関連項目:

レプリカ・サブエントリの属性の詳細は、『Oracle Identity Managementリファレンス』のOracleディレクトリ・レプリケーションのスキーマ要素に関する項を参照してください。

42.1.3 レプリケーション承諾エントリの理解

次のトピックでは、レプリケーション承諾エントリとその属性の概念について説明し、様々なLDAPレプリケーション承諾についても説明します。

42.1.3.1 レプリケーション承諾エントリについて

レプリケーション承諾エントリの識別名は、次のとおりです。

orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration

このエントリには、複数のノード間のレプリケーション承諾を定義する属性が含まれており、orclReplAgreementEntryオブジェクト・クラスに関連付けられます。LDAPノードのLDAPベースのレプリケーション承諾は、サプライヤのレプリカ・サブエントリの下に存在します。たとえば図42-3では、LDAPベースのレプリケーション承諾のエントリがorclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configurationで表されています。

42.1.3.2 レプリケーション承諾エントリの属性

表42-2に、レプリケーション承諾の属性を示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

表42-2 レプリケーション承諾エントリの属性

属性 説明 更新メカニズム デフォルト 使用可能な値

orclagreementid

レプリケーション承諾エントリの名前。

読取り専用

orclreplicadn

LDAPベースのレプリケーションのみ。レプリケーション承諾においてコンシューマを識別するためのレプリカの識別名。

読取り専用

DN

orclentryexclusionfilter

LDAPベースの一方向レプリケーションのみ。レプリケートしないエントリを指定するLDAPフィルタ文字列。

Oracle Internet Directory 11gリリース1 (11.1.1.9.0)以上に適用されます。

「orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングの構成」を参照してください。

LDAP

カッコで囲まれたLDAPフィルタ文字列。サポートされる最大長は、1500文字です。

たとえば: (sn=smith)

orclreplicationprotocol

レプリカへの変更伝播用のレプリケーション・プロトコル。値:

読取り専用

ODS_LDAP_1.0: LDAPベース

orclupdateschedule

新規の変更および再試行される変更の更新間隔。

LDAP

60 (秒)

0以上

orclhiqschedule

ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔。

LDAP

600 (秒)

60(秒)以上

orclldapconnkeepalive

レプリケーション・サーバーをディレクトリ・サーバーに常時接続するか、変更ログ処理が行われるたびに接続するかの指定。

LDAP

1

0: false

1: true

orcllastappliedchangenumber

コンシューマ・レプリカで転送または適用された最後の変更番号。LDAPベースの承諾の場合、この属性にはサブタイプが含まれます。書式は次のとおりです。

orcllastappliedchangenumber; status_type$supplier_replicaID$consumer_replicaID: Number

ここでstatus_typeはtransportまたはapplyであり、supplier_replicaIDおよびconsumer_replicaIDはLDAPのデータ・フローの方向を示し、Numberは最後に適用された変更番号です。

これは、Numberより小さい変更番号を持つsupplier_replicaIDからconsumer_replicaIDへの変更ログは、consumer_replicaIDで転送または適用されたことを示します。

読取り専用

orclexcludednamingcontexts

レプリケーションから除外される変更。

読取り専用

orclreplicationid

一方向、双方向またはpeer-to-peerレプリケーション・グループの一意の識別子

読取り専用

orclagreementtype

レプリケーション承諾のタイプ。

読取り専用

0: 一方向/読取り専用ファンアウト・レプリケーション承諾

1: 双方向/更新可能ファンアウト・レプリケーション承諾

2: LDAPベースのマルチマスター・レプリケーション承諾
42.1.3.3 LDAPベースのレプリケーション承諾について

LDAPベースのレプリケーションの場合、サプライヤとコンシューマの関係ごとに、別々のレプリケーション承諾があります。一方向レプリケーションの場合、単一の一方向レプリケーション承諾があります。

LDAPベースのレプリケーション承諾のエントリは、サプライヤとして機能するノードのレプリカ・サブエントリの直下にあります。したがって、サプライヤ・ノードに対するレプリケーション承諾は、次のようになります。

orclagreementID=unique_identifier_of_the_replication_agreement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration

同様に、コンシューマ・ノードに対するレプリケーション承諾は、次のようになります。

orclagreementID=unique_identifier_of_the_replication_agreeement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration

ファンアウト・レプリケーション承諾の場合、親ノードを調べることで、承諾エントリと関連付けられているノードを識別できます。たとえば、次のレプリケーション承諾エントリを見ます:

orclagreementID=000002,orclReplicaID=node_A,cn=replication configuration

この例では、orclagreementID=000002で表されたレプリケーション承諾がノードAと関連付けられていることを確認できます。これは、orclagreementID=000002の親がorclReplicaID=node_Aであるためです。

ノート:

  • コンテナ・エントリcn=replication configurationは、すべてのノードでレプリケートされますが、すべてのノードで同一ではない場合があります。

  • LDAPベースのレプリケーション承諾のorclreplicadn属性は、関連付けられるコンシューマ・ノードを指定します。

  • agreementtypeは、レプリケーション承諾のタイプを表します。orclagreementtypeの値は、表42-2を参照してください。

42.1.3.4 双方向LDAPベースのレプリケーション承諾の例

双方向レプリケーションの場合、サプライヤとコンシューマの関係ごとに、単一の双方向レプリケーション承諾か2つの一方向承諾のいずれかになります。次に、双方向レプリケーション承諾エントリの例を示します。

dn: orclagreementid=000002, orclreplicaid=stadd58_repl, cn=replication configuration
orclagreementid: 000002
orclreplicationprotocol: ODS_LDAP_1.0
orclreplicadn: orclreplicaid=stadd57_repl,cn=replication configuration
orclldapconnkeepalive: 1
orclagreementtype: 1
orclreplicationid: 000002
orcllastappliedchangenumber;transport$stadd57$stadd58: 106
orcllastappliedchangenumber;transport$stadd58$stadd57: 2421
orcllastappliedchangenumber;apply$stadd57$stadd58: 106
orcllastappliedchangenumber;apply$stadd58$stadd57: 2421
orclupdateschedule: 0
orclhiqschedule: 60
objectclass: orclReplAgreementEntry
objectclass: top

ノート:

これは双方向レプリケーション承諾であるため、orclagreementtypeの値は1となります。他のレプリケーション承諾タイプのorclagreementtypeの値は、表42-2を参照してください。

関連項目:

レプリケーション承諾エントリの属性の詳細は、『Oracle Identity Managementリファレンス』のOracleディレクトリ・レプリケーションのスキーマ要素に関する項を参照してください

42.1.4 レプリケーションのネーミング・コンテキスト・コンテナ・エントリ

このエントリには、LDAPネーミング・コンテキストのすべてのオブジェクトが含まれています。このエントリは相対識別名cn=replication namecontextを持ち、レプリケーション構成時にorclagreementIDエントリの下に作成されます。

次に、レプリケーションのネーミング・コンテキスト・コンテナ・エントリの例を示します。

dn: cn=replication namecontext,orclagreementid=000002, 
 orclreplicaid=myhost1_repl1,cn=replication configuration
objectclass: top
objectclass: orclcontainerOC
cn: replication namecontext

42.1.5 レプリケーションのネーミング・コンテキスト・オブジェクト・エントリの理解

次のトピックでは、レプリケーションのネーミング・コンテキスト・オブジェクト・エントリとその属性のコンテキストについて説明します。

42.1.5.1 レプリケーションのネーミング・コンテキスト・オブジェクト・エントリについて

このエントリには、LDAPネーミング・コンテキストのすべてのオブジェクトが含まれています。これらのオブジェクトは、レプリケーション・フィルタ・ポリシー、つまりLDAPベースの部分レプリカに対するレプリケーションに何を含めるか、あるいはレプリケーションから何を除外するかを指定します。

このエントリは、レプリケーション構成時にネーミング・コンテキスト・コンテナ・エントリの下に作成されます。これは構成可能です。たとえば、図42-3では、レプリケーションのネーミング・コンテキスト・オブジェクトは、cn=includednamingcontext000001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=UID_of_node_D,cn=replication configurationです。

42.1.5.2 レプリケーションのネーミング・コンテキスト・エントリ属性

表42-3に、レプリケーション・ネーミング・コンテキスト・エントリの属性を示します。

表42-3 レプリケーション・ネーミング・コンテキスト・エントリの属性

属性 説明

orclincludednamingcontexts

レプリケートされるネーミング・コンテキストのルート。orclincludednamingcontextsが"*"に設定されている場合、すべてのネーミング・コンテキストがレプリケートされます。この属性には、ネーミング・コンテキストを含めるレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。 

orclincludednamingcontexts ; supplier_replicaID$consumer_replicaiD: DN

この属性は単一の値です。ネーミング・コンテキスト・オブジェクトごとに、各方向に1つの一意のサブツリーのみを指定できます。

部分レプリケーションでは、orclexcluednamingcontexts属性に指定されたサブツリーを除き、ネーミング・コンテキストに含まれているサブツリーはすべてレプリケートされます。

この属性は変更可能です。

orclexcludednamingcontexts

含まれているネーミング・コンテキスト内に配置されている、レプリケーションから除外されるサブツリーのルート。この属性には、ネーミング・コンテキストを除外するレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。

orclexcludednamingcontexts; supplier_replicaID$consumer_replicaiD : DN

この属性は複数値です。orclincludednamingcontexts属性で指定したネーミング・コンテキスト内から、各方向で部分レプリケーションから除外する1つ以上のサブツリーを指定できます。

この属性は変更可能です。

orclexcludedattributes

含まれているネーミング・コンテキスト内にある、レプリケーションから除外する属性。orclexcludedattributesには、指定した属性を除外するレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。 

orclexcludedattributes; supplier_replicaID$consumer_replicaiD: attribute_name

この属性は複数値です。

この属性は変更可能です。
42.1.5.3 レプリケーション・ネーミング・コンテキスト・エントリの例

次に、レプリケーションのネーミング・コンテキスト・オブジェクト・エントリの例を示します。

dn:cn=namectx001,
cn=replication namecontext,
orclagreementid=unique_identifier_of_the_replication_agreement,
orclreplicaid=replica_id_of_node_A,
cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts; replica_id_of_node_A$ replica_id_of_node_B : c=us,cn=mycompany
orclexcludedattributes; replica_id_of_node_B$ replica_id_of_node_A : userPassword

この例では、次のレプリケーション・フィルタを指定しています。

  • ネーミング・コンテキストcn=mycompanyは、ノードAとノードBの双方向のレプリケーションに含まれます。

  • ネーミング・コンテキストc=us,cn=mycompanyは、ノードAからノードBへのレプリケーションでのみ除外されます。

  • userPassword属性は、ノードBからノードAへのレプリケーションで除外されます。

関連項目:

42.1.6 レプリケーション構成セットの理解

次のトピックでは、レプリケーション構成セットとその属性のコンテキストについて説明します。

42.1.6.1 レプリケーション構成セットについて

レプリケーション構成セットには、次の識別名があります。

cn=configset0,cn=osdrepld,cn=subconfigsubentry

表42-4に、次の識別名を持つレプリケーション構成セットの属性とその説明を示します。 

cn=configset0,cn=osdrepld,cn=subconfigsubentry

属性orcldebuglevelを除き、この識別名で加えた属性の変更内容を反映させるには、レプリケーション・サーバーを再起動する必要があります。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

42.1.6.2 レプリケーション構成セットの属性

次の表に、レプリケーション構成セットをその説明とともに示します。

表42-4 レプリケーション構成セットの属性

属性 説明 更新メカニズム デフォルト 使用可能な値

modifyTimestamp

エントリの作成または変更の日時。

読取り専用

modifiersName

エントリの作成者または変更者の名前

読取り専用

orclChangeRetryCount

管理者操作キューに移動される前に、変更エントリに対して行われる処理再試行回数。

LDAP

10

1以上。

orclThreadsPerSupplier;transport

変更ログを転送するために、各サプライヤで生成されたワーカー・スレッド数。

LDAP

1

1-100

orclThreadsPerSupplier;apply

変更ログを適用するために、各サプライヤで生成されたワーカー・スレッド数。

LDAP

5

1-100

orclreplautotune

transportタスクとapplyタスクに割り当てられたスレッドの数が、ロードに応じて動的に変化します。サーバーを自動調整するように設定した場合は、これらのタスク間で共有するスレッドの最大数を指定する必要があります。変更した後、サーバーを再起動します。

LDAP

1

0: オフ

1: オン

orclreplmaxworkers

ワーカー・スレッドの最大数。orclreplautotuneが設定されている場合は必須です。

LDAP

20

1-100

orclsdumpflag

スタック・ダンプを生成します。

(変更後、再起動します。)

LDAP

0

0: False

1: True

orclmaxlogfilesize

最大ログ・ファイル・サイズ(MB)

LDAP

1 MB

1以上

orclmaxlogfiles

ローテーション状態を保つログ・ファイルの最大数

LDAP

100

1以上

orclsizelimit

レプリケーション・サイクル当たりで処理する最大項目数

LDAP

1000

1-10000

orclconflresolution

レプリケーション競合の自動解消

LDAP

1

0: False

1: True

orclreplusesasl;digest-md5

レプリケーションのバインドにSASLを使用します。

LDAP

デフォルトでは属性が存在しません。

auth、auth-int、auth-conf

orclActivateReplication

orclOidInstanceNameおよびorclOidComponentNameにより指定されるレプリケーション・サーバーでレプリケーションをアクティブにすることを指定します。

LDAP

0

0: False

1: True

orclReplicationState

レプリケーション・サーバーのアクティブ化の状態

読取り専用、LDAP

0

0または存在しない: 非稼働(False)

1: 実行中

orcldebuglevel

レプリケーション・サーバーのデバッグのレベル

LDAP

0

値は加算方式です。

0: デバッグ・ログなし

2097152: レプリケーション・パフォーマンス・ログ

4194304: レプリケーション・デバッグ・ログ

8388608: ファンクション・コール・トレース

16777216: 大容量トレース・ログ

orclOidComponentName

レプリケーションがアクティブであるかアクティブ化されるOIDコンポーネントの名前

読取り専用

レプリケーションの設定中に設定

文字列

orclOidInstanceName

レプリケーションがアクティブであるかアクティブ化されるインスタンスのインスタンス番号

読取り専用

レプリケーションの設定中に設定

整数

orclReplAttrConflict

属性レベルの競合の解消時に最初にタイムスタンプまたは属性バージョンのいずれを適用する必要があるかを指定します。

LDAP

0

0: 最初にタイムスタンプ。

1: 最初にバージョン番号

42.1.7 ディレクトリ内のレプリケーション構成オブジェクトの例

この項では、ディレクトリ内のレプリケーション構成オブジェクトについて説明します。

この項で説明するレプリケーション・オブジェクトの例は、図42-1に示すレプリケーション環境に依存します。

図42-1 例: マルチマスター・レプリケーションおよびファンアウト・レプリケーション

この図については本文で説明しています。

図42-1では、ノードA、B、Cがマルチマスター・レプリケーション・グループを形成しています。ノードCは、4番目のノードDに対してレプリケーションを行い、ノードDはノードEにファンアウトします。

この環境のレプリケーション承諾は、次のとおりです。

  • ノードAには、ノードBおよびCとのマルチマスター関係を表す1つのレプリケーション承諾があります。

  • ノードBには2つのレプリケーション承諾があり、最初の承諾はノードAおよびCとのマルチマスター関係を表し、2番目の承諾はノードFとの関係を表します。BとFの間のレプリケーション承諾は双方向です。

  • ノードCには2つのレプリケーション承諾があり、最初の承諾はノードAおよびBとのマルチマスター関係を表し、2番目の承諾はノードDとの関係を表します。これは、Cがサプライヤとして機能し、ノードDがコンシューマとなる一方向レプリケーション承諾です。

  • ノードDには、2つのレプリケーション承諾があります。どちらのレプリケーション承諾も一方向です。1つは、ノードDが変更情報を消費するサプライヤ・ノードCとの関係を表し、もう1つは、ノードDがサプライヤとなるコンシューマ・ノードEとの関係を表しています。

  • ノードEには、ノードDとの一方向レプリケーション承諾が1つあります。ノードEはコンシューマです。

  • ノードFには、2つのレプリケーション承諾があります。1つは、ノードBとの関係を表し、もう1つは、ノードBとの関係を表しています。どちらも両方向レプリケーション承諾です。

  • ノードEには、ノードDとの一方向レプリケーション承諾が1つあります。ノードEはコンシューマです。

図42-2に、図42-1で説明したノードCに関連するDIT内のレプリケーション・オブジェクトを示します。

図42-2 例: ノードCについてのレプリケーション構成エントリ

この図については本文で説明しています。

ノードCの場合、ルートDSEにあるエントリcn=replication configurationには、次のRDNが含まれています。

  • orclagreementID=000001: ノードCをノードAおよびノードBに関連付けるマルチマスター・レプリケーション承諾。

  • orclReplicaID=UID_of_node_C: ノードCの一意識別子。ノードCに関する情報が含まれています。

  • orclagreementID=000002: サプライヤ・ノードCとコンシューマ・ノードD間の関係を表す一意の識別子。この場合、ノードCが親になっているため、orclagreementID=000002がサプライヤ・ノードCのレプリケーション承諾です。

    このエントリには、orclreplicaDN属性が含まれています。この属性の値は、レプリケーション承諾がノードCに含まれているコンシューマ・ノードDのレプリカ・エントリDNです。

  • cn=replication DN: ノードC上のディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーにバインドするときに使用するバインド識別名。

  • cn=replication namecontext: レプリケーションに含まれるネーミング・コンテキストに関する情報のコンテナ。

  • cn=includednamingcontext000001およびcn=namingcontext002: レプリケーションに含まれているか、またはレプリケーションから除外されている実際のオブジェクト。レプリケーションに含まれるネーミング・コンテキストには、レプリケーションから除外する1つ以上のサブツリーを指定できます。また、レプリケーションから除外する属性も指定できます。

図42-3に、図42-1で説明したノードDに関連するDIT内のレプリケーション承諾エントリを示します。

図42-3 例: ノードDについてのレプリケーション構成エントリ

この図については本文で説明しています。

ノードDの場合、ルートDSEにあるエントリcn=replication configurationには、次のRDNが入っています。

  • orclReplicaID=UID_of_node_D: ノードDの一意識別子。ノードDに関する情報が含まれています。

  • orclagreementID=000003: サプライヤ・ノードDとコンシューマ・ノードE間の関係を表す一意の識別子。この場合、ノードDが親になっているため、orclagreementID=000003がサプライヤ・ノードDのレプリケーション承諾です。

    このエントリには、orclreplicaDN属性が含まれています。この属性の値は、レプリケーション承諾がノードDに含まれているコンシューマ・ノードEのDNです。

  • cn=replication DN: ノードD上のディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーにバインドするときに使用するバインド識別名。

  • cn=replication namecontext: レプリケーションに含まれるネーミング・コンテキストに関する情報のコンテナ。

  • cn=namingcontext001およびcn=namingcontext002レプリケーションに含まれるネーミング・コンテキストを指定するオブジェクト。レプリケーションに含まれるネーミング・コンテキストには、レプリケーションから除外する1つ以上のサブツリーまたは特定の属性を指定できます。

42.2 コマンド行を使用したレプリケーション構成属性の管理

ほとんどの属性は、コマンド行からldapmodifyを使用して変更できます。

コマンド行構文は次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

LDIFファイルの内容は、識別名および実行されている操作によって異なります。

レプリケーション構成属性を変更するためのLDIFファイルの例は、「コマンド行を使用したレプリケーションの管理およびモニタリングの概要」を参照してください。