この章では、Oracle Internet Directoryレプリケーション・サーバーを制御する構成属性について説明します。それらの属性はDIT内の特定コンテナに格納されます。
具体的なレプリケーション管理タスクは、第42章「レプリケーションの管理および監視」を参照してください。
この章の項目は次のとおりです。
この概要の項目は次のとおりです。
ノードに関するすべてのレプリケーション情報は、ルート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
orclreplicaid=Replica_ID,cn=replication configuration
このサブエントリは、インストール時にレプリケーション構成コンテナの下に作成されます。これには、表すノードの特性を識別し、定義する属性が含まれます。
表41-1に、レプリカ・サブエントリの属性を示します。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。
表41-1 レプリカ・サブエントリの属性
属性 | 説明 | 更新メカニズム | デフォルト | 使用可能な値 |
---|---|---|---|---|
ディレクトリ・データベースの一意の識別子。インストール時に初期化されます。ルートDSEのorclreplicaidと一致します。 |
読取り専用 |
hostname_ORACLESID |
整数 |
|
このレプリカに接続する際に使用されるアドレス。 |
EM、LDAP |
有効なldapURI書式 |
||
|
EM、LDAP |
有効なldapURI書式 |
||
読取り専用、読取り/書込みなどのレプリカのタイプを定義します。 |
EM、LDAP |
0(読取り/書込み) |
0: 読取り/書込み 1: 読取り専用 2: パイロット |
|
レプリカをパイロット(テスト)・モードにするかどうかを定義します。 |
|
0 |
0: FALSE 1: TRUE |
|
レプリカの状態を定義します。 |
EM、LDAP |
0、1、2、6または8を設定できます。サーバーは他の値を設定します。表D-1を参照してください。 |
||
レプリカがパイロット(テスト)・モードに切り替わった時刻。 |
読取り専用 |
時間 |
注意: WindowsシステムではorclReplicaState の値を0 に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。 |
図41-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 Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。 |
レプリケーション承諾エントリの識別名は、次のとおりです。
orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration
このエントリには、複数のノード間のレプリケーション承諾を定義する属性が含まれており、orclReplAgreementEntry
オブジェクト・クラスに関連付けられます。承諾には次の2つの種類があります。
Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾。アドバンスト・レプリケーション・ノードのレプリケーション承諾は、レプリケーション構成セットの下に存在します。たとえば、図41-2では、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾のエントリがorclagreementID=000001,cn=replication configuration
で表されています。
LDAPベースのレプリケーション承諾。LDAPノードのレプリケーション承諾は、サプライヤのレプリカ・サブエントリの下に存在します。たとえば図41-3では、LDAPベースのレプリケーション承諾のエントリがorclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configuration
で表されています。
表41-2に、レプリケーション承諾の属性を示します。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。
表41-2 レプリケーション承諾エントリの属性
属性 | 説明 | 更新メカニズム | デフォルト | 使用可能な値 |
---|---|---|---|---|
レプリケーション承諾エントリの名前。 |
読取り専用 |
|||
LDAPベースのレプリケーションのみ。レプリケーション承諾においてコンシューマを識別するためのレプリカの識別名。 |
読取り専用 |
DN |
||
レプリカへの変更伝播用のレプリケーション・プロトコル。指定可能な値は次のとおりです。 |
読取り専用 |
ODS_ASR_1.0: Oracle Databaseアドバンスト・レプリケーション・ベース ODS_LDAP_1.0: LDAPベース |
||
Oracle Databaseアドバンスト・レプリケーション・ベースのグループのみ。このレプリケーション・グループのすべてのノードのOrclreplicaid値。このリストは、グループのすべてのノードで同一であることが必要です。この属性は変更可能です。 |
LDAP |
|||
新規の変更および再試行される変更の更新間隔。 |
EM、LDAP |
60(秒) |
0以上 |
|
ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔。 |
EM、LDAP |
600(秒) |
60(秒)以上 |
|
レプリケーション・サーバーをディレクトリ・サーバーに常時接続するか、変更ログ処理が行われるたびに接続するかの指定。 |
EM、LDAP |
1 |
0: FALSE 1: TRUE |
|
コンシューマ・レプリカで転送または適用された最後の変更番号。LDAPベースの承諾の場合、この属性にはサブタイプが含まれます。書式は次のとおりです。 orcllastappliedchangenumber; status_type$supplier_replicaID$consumer_replicaID: Number ここでstatus_typeは これは、 Oracle Databaseアドバンスト・レプリケーション・ベースの承諾の場合、ベース型のみ使用されます。 |
読取り専用 |
|||
レプリケーションから除外される変更。 Oracle Databaseアドバンスト・レプリケーション・ベースの承諾にのみ適用されます。LDAPレプリケーションは、レプリケーション・ネーミング・コンテキスト・エントリ(表41-3を参照)を使用します。 |
読取り専用 |
|||
一方向、双方向またはpeer-to-peerレプリケーション・グループの一意の識別子 |
読取り専用 |
|||
レプリケーション承諾のタイプ。 |
読取り専用 |
0: 一方向/読取り専用ファンアウト・レプリケーション承諾 1: 双方向/更新可能ファンアウト・レプリケーション承諾 2: LDAPベースのマルチマスター・レプリケーション承諾 3: Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション承諾 |
アドバンスト・レプリケーションの場合は、各ノードのレプリケーション承諾にグループ内のすべてのノードがリストされます。これは、ローカル・ディレクトリ・サーバーのパーティション化されたネーミング・コンテキストなどのローカル・オプションを除き、各ノードで同じです。
このタイプのレプリケーション承諾のエントリは、コンテナ・エントリcn=replication configuration
の直下に存在します。たとえば、このような承諾のDNは、orclagreementID=000001,cn=replication configuration
のようになります。
LDAPベースのレプリケーションの場合、サプライヤとコンシューマの関係ごとに、別々のレプリケーション承諾があります。一方向レプリケーションの場合、単一の一方向レプリケーション承諾があります。
LDAPベースのレプリケーション承諾のエントリは、サプライヤとして機能するノードのレプリカ・サブエントリの直下にあります。したがって、サプライヤ・ノードに対するレプリケーション承諾は、次のようになります。
orclagreementID=
unique_identifier_of_the_replication_agreement
, orclReplicaID=
unique_identifier_of_supplier_node
, cn=replication configuration
同様に、コンシューマ・ノードに対するレプリケーション承諾は、次のようになります。
orclagreementID=
unique_identifier_of_the_replication_agreement
, 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
であるためです。
注意:
|
双方向レプリケーションの場合、サプライヤとコンシューマの関係ごとに、単一の双方向レプリケーション承諾か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 の値は、表41-2「レプリケーション承諾エントリの属性」を参照してください。 |
関連項目: レプリケーション承諾エントリの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。 |
このエントリには、LDAPネーミング・コンテキストのすべてのオブジェクトが含まれています。
このエントリは相対識別名cn=replication namecontext
を持ち、レプリケーション構成時にorclagreementID
エントリの下に作成されます。次に、レプリケーションのネーミング・コンテキスト・コンテナ・エントリの例を示します。
dn: cn=replication namecontext,orclagreementid=000002, orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: top objectclass: orclcontainerOC cn: replication namecontext
このエントリには、すべてのLDAPネーミング・コンテキスト・オブジェクトが含まれます。これらのオブジェクトは、レプリケーション・フィルタ・ポリシー、つまりLDAPベースの部分レプリカに対するレプリケーションに何を含めるか、あるいはレプリケーションから何を除外するかを指定します。
注意: Oracle Databaseアドバンスト・レプリケーション・ベースの承諾では、ネーミング・コンテキストを含めたり、属性を除外したりできません。アドバンスト・レプリケーション承諾では、表41-2で説明されているベース属性のorclexcludednamingcontexts を使用します。 |
このエントリは、レプリケーション構成時にネーミング・コンテキスト・コンテナ・エントリの下に作成されます。これは構成可能です。たとえば、図41-3では、レプリケーションのネーミング・コンテキスト・オブジェクトは、cn=includednamingcontext000001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=
UID_of_node_D
,cn=replication configuration
です。
表41-3に、レプリケーション・ネーミング・コンテキスト・エントリの属性を示します。Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用してレプリケーションを設定する場合は、各属性を「有効範囲」ページで設定します。
表41-3 レプリケーション・ネーミング・コンテキスト・エントリの属性
属性 | 説明 |
---|---|
レプリケートされるネーミング・コンテキストのルート。orclincludednamingcontextsが"
orclincludednamingcontexts ; supplier_replicaID$consumer_replicaiD: DN
この属性は単一の値です。ネーミング・コンテキスト・オブジェクトごとに、各方向に1つの一意のサブツリーのみを指定できます。 部分レプリケーションでは、orclexcluednamingcontexts属性に指定されたサブツリーを除き、ネーミング・コンテキストに含まれているサブツリーはすべてレプリケートされます。 この属性は変更可能です。 |
|
含まれているネーミング・コンテキスト内に配置されている、レプリケーションから除外されるサブツリーのルート。この属性には、ネーミング・コンテキストを除外するレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。 orclexcludednamingcontexts; supplier_replicaID$consumer_replicaiD : DN この属性は複数値です。orclincludednamingcontexts属性で指定したネーミング・コンテキスト内から、各方向で部分レプリケーションから除外する1つ以上のサブツリーを指定できます。 この属性は変更可能です。 |
|
含まれているネーミング・コンテキスト内にある、レプリケーションから除外する属性。 orclexcludedattributes; supplier_replicaID$consumer_replicaiD: attribute_name この属性は複数値です。 この属性は変更可能です。 |
次に、レプリケーションのネーミング・コンテキスト・オブジェクト・エントリの例を示します。
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へのレプリケーションで除外されます。
関連項目:
|
cn=configset0,cn=osdrepld,cn=subconfigsubentry
表41-4に、次の識別名を持つレプリケーション構成セットの属性とその説明を示します。
cn=configset0,cn=osdrepld,cn=subconfigsubentry
属性orcldebuglevel
を除き、この識別名で加えた属性の変更内容を反映させるには、レプリケーション・サーバーを再起動する必要があります。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。
表41-4 レプリケーション構成セットの属性
属性 | 説明 | 更新メカニズム | デフォルト | 使用可能な値 |
---|---|---|---|---|
エントリの作成または変更の日時。 |
読取り専用 |
|||
エントリの作成者または変更者の名前 |
読取り専用 |
|||
管理者操作キューに移動される前に、変更エントリに対して行われる処理再試行回数。 |
EM、LDAP |
10 |
1以上。 |
|
変更ログを転送するために、各サプライヤで生成されたワーカー・スレッド数。 |
EM、LDAP |
1 |
1-100 |
|
|
変更ログを適用するために、各サプライヤで生成されたワーカー・スレッド数。 |
EM、LDAP |
5 |
1-100 |
transportタスクとapplyタスクに割り当てられたスレッドの数が、ロードに応じて動的に変化します。サーバーを自動調整するように設定した場合は、これらのタスク間で共有するスレッドの最大数を指定する必要があります。変更した後、サーバーを再起動します。 |
EM、LDAP |
1 |
0: 無効 1: 有効 |
|
ワーカー・スレッドの最大数。 |
EM、LDAP |
20 |
1-100 |
|
スタック・ダンプを生成します。 (変更後、再起動します。) |
EM、LDAP |
0 |
0: FALSE 1: TRUE |
|
最大ログ・ファイル・サイズ(MB) |
EM、LDAP |
1MB |
1以上 |
|
ローテーション状態を保つログ・ファイルの最大数 |
EM、LDAP |
100 |
1以上 |
|
レプリケーション・サイクル当たりで処理する最大項目数 |
EM、LDAP |
1000 |
1-10000 |
|
レプリケーション競合の自動解消 |
EM、LDAP |
1 |
0: FALSE 1: TRUE |
|
レプリケーション・バインド用SASLを使用します。 |
EM、LDAP |
デフォルトでは属性が存在しません。 |
auth、auth-int、auth-conf |
|
|
EM、LDAP |
0 |
0: FALSE 1: TRUE |
|
レプリケーション・サーバーのアクティブ化の状態 |
EM、LDAPを使用し、読取り専用 |
0 |
0または存在しない: 非稼働(False) 1: 稼働中 |
|
レプリケーション・サーバーのデバッグのレベル |
EM、LDAP |
0 |
値は加算方式です。 0: デバッグ・ログなし 2097152: レプリケーション・パフォーマンス・ログ 4194304: レプリケーション・デバッグ・ログ 8388608: ファンクション・コール・トレース 16777216: 大容量トレース・ログ |
|
レプリケーションがアクティブであるかアクティブ化されるOIDコンポーネントの名前 |
読取り専用 |
レプリケーションの設定中に設定 |
文字列 |
|
レプリケーションがアクティブであるかアクティブ化されるインスタンスのインスタンス番号 |
読取り専用 |
レプリケーションの設定中に設定 |
整数 |
|
|
属性レベルの競合の解消時に最初にタイムスタンプまたは属性バージョンのいずれを適用する必要があるかを指定します。 |
EM、LDAP |
0 |
0: 最初にタイムスタンプ。 1: 最初にバージョン番号 |
この項で説明するレプリケーション・オブジェクトの例は、図41-1に示すレプリケーション環境に依存します。
図41-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はコンシューマです。
図41-2に、図41-1で説明したノードCに関連するDIT内のレプリケーション・オブジェクトを示します。
ノード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つ以上のサブツリーを指定できます。また、レプリケーションから除外する属性も指定できます。
図41-3に、図41-1で説明したノードDに関連するDIT内のレプリケーション承諾エントリを示します。
ノード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つ以上のサブツリーまたは特定の属性を指定できます。
この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できるフィールドと対応するレプリケーション構成属性を要約して示します。具体的な手順は、第42章「レプリケーションの管理および監視」を参照してください。
Fusion Middleware ControlのOracle Internet Directoryの「共有プロパティ」ページを使用して、レプリケーション属性の一部を構成できます。「Oracle Internet Directory」メニューから、「管理」、「共有プロパティ」、「レプリケーション」の順に選択します。構成を変更した後、「適用」を選択します。対応関係は次のとおりです。
一部の構成属性は、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードで選択または入力するいくつかの値によって制御されます。たとえば、レプリケーション・ウィザードの「スケジュール」ページでの選択によって表41-6「レプリケーション・スケジュール属性」に示す属性が制御されます。
レプリケーションを構成すると、ウィザードで他の属性が適切に設定されます。たとえば、属性orclreplicauri
は、ウィザードの「レプリカ」ページのフィールドを連結して形成されます。
ほとんどの属性は、コマンドラインからldapmodify
を使用して変更できます。コマンドライン構文は次のとおりです。
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
LDIFファイルの内容は、識別名および実行されている操作によって異なります。
レプリケーション構成属性を変更するためのLDIFファイルの例は、第42.3項「コマンドラインを使用したレプリケーションの管理および監視」を参照してください。