ディレクトリ・データのレプリケーション

32.1 レプリケーションを構成する前の前提条件について

レプリケーションを構成しようとする前に、前提条件を必ず確認してください。

次の点に注意してください。

使用しているデプロイメントでデフォルトのマルチマスター・レプリケーション・モデルが適切かどうか判別します。

マルチマスター・レプリケーション・モデルは、デフォルトではゆるやかな一貫性を持つモデルです。つまり、1つのサーバー上で加えられた変更がトポロジ内の他のサーバーに非同期的にレプリケートされます。このため、同一エントリが別々のサーバーで同時に変更される可能性があります。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。WANの各種属性(待機時間など)によってレプリケーションの競合が発生する可能性が高くなる場合があります。競合の解決は一般に自動的に行われます。優先される変更は、いくつかの競合ルールによって判断されます。場合によっては、競合を手動で解決する必要があります。

ノート:

一部のデプロイメント・シナリオでは、デフォルトのゆるやかな一貫性モデルが不適なことがあります。このような場合は、レプリケーションを保証モードで動作するように構成できます。詳細は、「保証レプリケーションの構成」を参照してください。
SSLを有効にする必要があります。レプリケーションは必ず、保護された接続を介して行われます。レプリケーション・セッションの双方のサーバーは、SSL証明書を使用して相手側サーバーに対して認証される必要があります。アクセス制御や権限は強制されません。
すべてのディレクトリ・サーバーを同じように構成する場合にのみ、Oracle Unified Directoryの初回インストール時にグラフィカルな設定ユーティリティを使用してレプリケーションを設定できます。
setupコマンドを使用してコマンド行モードでレプリケーションを構成することはできません。setupコマンドでディレクトリ・サーバーを設定する場合は、dsreplicationコマンドを使用してサーバー間のレプリケーションを構成する必要があります。
どのトポロジでも、レプリケーション・サーバーに障害が発生した場合の可用性を確保するために、2つのレプリケーション・サーバーが必要とされます。レプリケーション・サーバーは、環境内で発生したあらゆる変更を追跡する役割を担います。各レプリケーション・サーバーには、トポロジ内の他のレプリケーション・サーバーをすべて列挙したリストが格納されます。

ノート:
レプリケーション・アーキテクチャでは、各レプリケーション・サーバーは、トポロジ内の他のすべてのレプリケーション・サーバーに接続されています。
レプリケート対象トポロジでDynamic Host Configuration Protocol (DHCP)を使用する場合、最初の構成後レプリケーション・サーバーのホスト名を変更できません。
この項の各例では、すでに2つのディレクトリ・サーバーがインストールされており、その一方にデータが移入されていることを前提としています。2つのディレクトリ・サーバーは同じホスト・マシン上にインストールできますが、その場合は別々のポート番号を割り当てる必要があります。

32.2 `dsreplication`によるデータ・レプリケーションの理解

dsreplicationコマンドは、管理コネクタを介してSSL上でサーバー構成にアクセスします。

詳細は、「サーバーへの管理トラフィックの管理」を参照してください。

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

32.2.1 `dsreplication`による2つのサーバー間のレプリケーションの理解

dsreplication enableコマンドのインスタンスを複数実行して、複数のディレクトリ・サーバー間のレプリケーションを設定することはできません。トポロジ内のディレクトリとレプリケーション・サーバーのペアごとにdsreplication enableコマンドを個別に実行する必要があります。

図32-1 基本的なレプリケーション・アーキテクチャ

「図32-1 基本的なレプリケーション・アーキテクチャ」の説明

この項には次のトピックが含まれます:

32.2.1.1 `dsreplication`による2つのサーバー間のレプリケーションの有効化

2つのディレクトリ・サーバー間のレプリケーションを有効にするには:

dsreplication enableコマンドを実行します。

次の構成例では、2つのディレクトリ・サーバー(host1のディレクトリ・サーバーAとhost2のディレクトリ・サーバーB)間で"dc=example,dc=com"にあるデータのレプリケーションを有効にします。どちらのディレクトリ・サーバーもデフォルトの管理ポート(4444)を使用します。このコマンドは、host1のポート8989にレプリケーション・サーバー・インスタンスを1つ作成し、host2のポート8989にもう1つレプリケーション・サーバー・インスタンスを作成します。

$ dsreplication enable 
  --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
  --bindPasswordFile1 pwd.txt --replicationPort1 8989 \
  --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \
  --bindPasswordFile2 pwd.txt --replicationPort2 8989 \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n

--adminUIDオプションと--adminPasswordFileオプションは、レプリケーション・ドメインのグローバル管理者を指します。詳細は、「管理者の管理」を参照してください。-Xオプションは、すべてのサーバー証明書を信頼する必要があることを指定します。-n (--no-prompt)オプションは、このコマンドを非対話型モードで実行するように指定します。dsreplicationコマンドの全グローバル・オプションの詳細は、コマンド行でdsreplication -helpと入力してください。

ホストに構成されたネットワーク・インタフェース(ループバック・アドレスを含まない)が複数ある場合は、--host1および--host2に値を指定するときにこれらを指定できます。値を区切るには、カンマを使用します。たとえば:

$ dsreplication enable 
  --host1 interface1,interface2,interface3 --port1 4444 --bindDN1 \
    "cn=Directory Manager" \
  --bindPasswordFile1 pwd.txt --replicationPort1 8989 \
  --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \
  --bindPasswordFile2 pwd.txt --replicationPort2 8989 \

新しいディレクトリ・サーバーをレプリケーション・トポロジに追加するには、新しいサーバーの接続情報およびすでにレプリケートされているサーバーの情報を指定してdsreplication enableを実行します。

既存のレプリケーション・トポロジにレプリカを追加するには、追加する各レプリカに対して、次のコマンドを実行します。

$ dsreplication enable 
  --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
  --bindPasswordFile1 pwd.txt --replicationPort1 8989 \
  --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \
  --bindPasswordFile2 pwd.txt --replicationPort2 8989 \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n

ここで、--[parameter]1では、レプリケーション・トポロジにすでに追加されている既存のレプリカを指定し、--[parameter]2では追加される新しいレプリカを指定します。

32.2.1.2 レプリケーション・サーバーの作成場所の制御

dsreplication enableを2つのサーバー間で使用すると、それぞれのホスト上でレプリケーション・サーバーが自動的に構成されます。レプリケーション・サーバーを各ホストに作成することなく、2つのディレクトリ・サーバー間のレプリケーションを構成する必要がある場合があります。--noReplicationServer1オプションまたは--noReplicationServer2オプションを使用すれば、追加のレプリケーション・サーバーを作成せずに、ディレクトリ・サーバーをトポロジに追加できます。シングル・ポイント障害を回避するために、レプリケートするトポロジ内にはレプリケーション・サーバーが少なくとも2つ必要であることに注意してください。

また、2つのサーバー間のレプリケーションを有効にし、一方のサーバーにのみレプリケーション・サーバー(ディレクトリ・サーバーではありません)を作成するようにも指定できます。これを実現するには、--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを使用します。このオプションを指定すると、そのサーバーで変更ログとレプリケーション・ポートが構成されます。そのサーバーには、レプリケートされたデータは格納されません。

32.2.2 `dsreplication`によるレプリケート対象サーバーの初期化

dsreplication initializeコマンドを使用して、レプリケート対象サーバーを別のレプリケーション対象サーバーからのデータで初期化します。

次のコマンドは、host2のベースDN "dc=example,dc=com"を、host1に格納されているデータによって初期化します:

$ dsreplication initialize --baseDN "dc=example,dc=com" \
  --adminUID admin --adminPasswordFile pwd.txt \
  --hostSource host1 --portSource 4444 \
  --hostDestination host2 --portDestination 4444 -X -n

32.2.3 `dsreplication`によるトポロジ全体の初期化

トポロジに3つ以上のディレクトリ・サーバーがある場合は、dsreplication intialize-allコマンドを使用すると、すべてのレプリカを同時に初期化できます。このコマンドはソース・ホストの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。

次のコマンドは、レプリケーションが有効になっているすべてのサーバーを、host1のベースDN "dc=example,dc=com"のコンテンツで初期化します:

$ dsreplication initialize-all --hostname host1 --port 4444 \
  --baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt

32.2.4 レプリケート・トポロジのテスト

レプリケーションの動作をテストする最も簡単な方法は、1つのディレクトリ・サーバー上で変更を適用し、その変更が別のディレクトリ・サーバーにレプリケートされたことを確認するという方法です。

前述の手順で設定したレプリケーション・トポロジをテストするには:

ldapmodifyを使用して、host1上のエントリを変更します。
ldapsearchを使用して、その変更がhost2に伝播されていることを確認します。

32.2.5 `dsreplication`によるレプリケート・トポロジのステータスの取得

トポロジ内の任意のディレクトリ・サーバーの接続詳細を使用して、トポロジ全体のステータスを取得できます。dsreplication statusコマンドを使用すると、トポロジ内のディレクトリ・サーバーのリストが表示され、サーバー間で未伝播の変更があれば一緒に表示されます。

次のコマンドは、前述の手順で設定したトポロジのステータスを表示します:

$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \
  --hostname host1 --port 4444

32.2.6 `dsreplication`による既存の2つのレプリケート・トポロジのマージ

2つのレプリケート対象トポロジをマージするには、各トポロジの1つのサーバー同士のレプリケーションを有効にします。

2つのレプリケート対象トポロジをマージするには、dsreplication enableコマンドを使用します。

たとえば、レプリケート対象トポロジ(例: トポロジA)にはhost1、host2およびhost3が属しており、レプリケート対象トポロジ(例: トポロジB)にはhost4、host5およびhost6が属している場合、次のコマンドはこの2つのトポロジを効果的にマージします。
```
$ dsreplication enable \
  --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
  --bindPasswordFile1 pwd.txt --replicationPort1 8989 \
  --host2 host4 --port2 4444 --bindDN2 "cn=Directory Manager" \
  --bindPasswordFile2 pwd.txt --replicationPort2 8989 \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \
  -X -n
```
この例では、host1とhost4の両ホストにディレクトリ・サーバーとレプリケーション・サーバーが1つずつ含まれていると仮定しています。含まれていない場合は、ディレクトリ・サーバーまたはレプリケーション・サーバーが自動的に構成されます。
高可用性を確保するには、マージ時にオフラインまたは使用不可であったすべてのサーバーに対して、次のステップを実行する必要があります:
1. dsreplication enableを使用して、接尾辞cn=admin dataのコンテンツを初期化します。
  
  マージ時に使用可能であったサーバーの1つを使用して個別にサーバーを初期化することも、dsreplication initialize-allを使用することもできます。
2. dsconfigコマンドを使用してレプリケーション・サーバーのリストを更新します。

既存の2つのレプリケート・トポロジのマージに関する次の制限事項に注意してください。

このマージの実行時には、両方のトポロジ内のサーバーがすべて起動され実行されている必要があります。

いずれかのサーバーがオフラインである場合、dsreplicationではその構成を更新できません。マージの実行時にオフラインであったサーバーが再びオンラインになっても、このサーバーにもう一方のトポロジ内のレプリケーション・サーバーへの参照が追加されることはありません。
ドメインIDまたはレプリケーション・サーバーIDが2つのトポロジ間で競合している場合は、マージを実行できません。

つまり、トポロジAのサーバーがトポロジBのサーバーと同じレプリケーション・サーバーIDやドメインIDを持つことはできません。

IDが競合している場合は、最初のサーバー(--host1)のIDを使用して競合が解消されます。その後、--host1と同じトポロジに属すサーバーをソースとして使用して、最新の状態でないサーバーをすべて再初期化する必要があります。
両方のレプリケーション・トポロジで同一のグローバル管理者が定義されている必要があります。

32.2.7 `dsreplication`による特定のレプリケーション・ドメインに対するレプリケーションの無効化

dsreplication disableコマンドを使用して、特定のレプリケーション・ドメインに対するレプリケーションを無効化できます。

特定のドメインでのレプリケーションを無効にするには、dsreplication disableコマンドを使用します。
次のコマンドは、"dc=example,dc=com"にあるデータのレプリケーションを無効にします。
```
$ dsreplication disable --hostname host1 --port 4444 --adminUID admin \
  --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n
```
このコマンドは、そのドメインのディレクトリ・サーバーからレプリケーション構成を削除します。無効にするドメインがこのディレクトリ・サーバー・インスタンス上でレプリケートされている唯一のドメインである場合は、このインスタンス上のレプリケーション・サーバーも無効になります。レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。
レプリケーション・サーバー自体を(変更ログとレプリケーション・ポートを含めて)無効にするには、次のコマンドを使用します:
```
$ dsreplication disable --hostname host1 --port 4444 -X -n \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \
  --disableReplicationServer
```
レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。

レプリケーション・サーバーの無効化に関するノート

レプリケーション・サーバーを無効にすると、レプリケーション構成が削除されますが、レプリケーション・サーバーのデータベースは削除されません。したがって、レプリケーション・サーバーを誤って無効にしてしまった場合には、レプリケーションの変更記録を取得できます。この接尾辞でのレプリケーションを再度有効にする必要がなければ、レプリケーション・サーバーのデータベースを手動で削除してください(たとえば: $rm changelogDB/*)。

レプリケーションを無効にして再度有効にした場合、その間にそのサーバーで行われた変更はレプリケートされません。このため、レプリケーションを無効にした期間中はそのサーバーでの変更を禁止するか、変更が発生した場合には、そのサーバーからトポロジ内の残りの各サーバーを再同期する必要があります。

32.3 OUDSMを使用したデータ・レプリケーションの構成

Oracle Unified Directory Services Manager (OUDSM)を使用して実行できるサーバー構成の多くは、「Directory Manager」タブから行います。ただし、レプリケーション構成を管理するには、「Directory Manager」タブまたは「トポロジ・マネージャ」タブのいずれかを使用できます。

個別のサーバーやレプリケートされた接尾辞に固有のレプリケーション構成プロパティを表示または構成するには、「Directory Manager」タブを選択します。
既存のトポロジの管理または新しいトポロジの作成をレプリケーション構成ウィザードを使用して行うには、「トポロジ・マネージャ」タブを選択します。

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

32.3.1 OUDSMを更新する場合の考慮事項

レプリケーション・トポロジでOUDSMの複数インスタンスを使用している場合は、Oracle Unified Directory Services Manager (OUDSM)の更新の準備を行う際に、次の点を必ず考慮してください。

次の点に注意してください。

1つのOUDSMインスタンスを更新する場合は、すべてのOUDSMとレプリケートされたインスタンスを更新する必要があります。
OUDSMを更新する場合は、Oracle Unified Directoryも同じバージョンに更新する必要があります。更新されたOUDSMのバージョンが、Oracle Unified Directoryの前のバージョンで動作するかどうかは保証されません。

ノート:

Oracle Unified DirectoryおよびOracle Unified Directory Services Managerの更新の詳細は、『Oracle Unified Directoryのインストール』のOracle WebLogic ServerでのOracle Unified Directory Services Managerの更新に関する項を参照してください。

32.3.2 既存のレプリケーション・サーバーの構成の表示または変更

既存のレプリケーション・サーバーの構成を表示または変更するには、Oracle Unified Directory Services Manager (OUDSM)で「Directory Manager」タブを選択します。

既存のレプリケーション・サーバーを表示または変更するには:

「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「構成」サブタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」セクションで、「レプリケーション・サーバー」をクリックします。

「レプリケーション・サーバー」ページが表示されます。
「レプリケーション・サーバー」プロパティを表示または変更します。

使用可能なすべてのプロパティとその値の詳細は、『Oracle Unified Directory構成リファレンス』のレプリケーション・サーバーに関する項を参照してください。
変更を保存する場合は「適用」をクリックします。

32.3.3 レプリケートされた接尾辞の構成の表示または変更

レプリケートされた接尾辞の構成を表示または変更するには、Oracle Unified Directory Services Managerで「Directory Manager」タブを選択します。

レプリケートされた接尾辞の構成を表示または変更するには:

「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」セクションで、「レプリケートされたサフィックス」ノードを開いてから表示または変更する接尾辞を選択します。
「メイン」サブタブをクリックします。

「メイン」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。

使用可能なすべてのプロパティとその値の詳細は、『Oracle Unified Directory構成リファレンス』のレプリケーション・ドメインに関する項を参照してください。
「保証レプリケーション」サブタブをクリックします。

「保証レプリケーション」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。

使用可能なすべてのプロパティとその値の詳細は、『Oracle Unified Directory構成リファレンス』のレプリケーション・ドメインに関する項を参照してください。
「部分レプリケーション」サブタブをクリックします。

「部分レプリケーション」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。

使用可能なすべてのプロパティとその値の詳細は、『Oracle Unified Directory構成リファレンス』のレプリケーション・ドメインに関する項を参照してください。

32.3.4 「Directory Manager」タブでのレプリケーション構成ウィザードについて

新しいトポロジを作成したり、既存のトポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。

次の条件のいずれかが真の場合、「Directory Manager」タブからレプリケーション構成ウィザードを起動できます。

レプリケーション・トポロジが存在しない。「新しいトポロジの最初からの作成」を参照してください。
レプリケーション・トポロジは存在するが、現在のサーバーが追加されていないか、現在のサーバーが部分的にレプリケーション用に構成されているのみである。「既存のトポロジへのサーバーの追加」を参照してください。

32.3.4.1 新しいトポロジの最初からの作成

新しいトポロジを最初から作成するには:

「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」ペインで、「レプリケーション構成」を選択します。

「レプリケーション構成」ページが表示されます。
レプリケーション構成ウィザードを起動するには、「構成」をクリックします。
「レプリケーション・オプション」ページで、「新規トポロジを最初から作成しますか。」を選択します。

「次」をクリックします。
「サーバーの識別」ページで、構成対象である2つ以上のソース・サーバーについて、次の情報を入力します。
- 「ホスト」。完全修飾ドメイン名を使用してサーバー名を入力します。
- 「管理ポート」。管理ポート番号を入力します。デフォルトは4444です。
- 「管理ユーザー名」。サーバーの管理者のDNを入力します。
- 「管理者パスワード」。指定した管理者のパスワードを入力します。
(オプション)このページでは、次のことも行えます。
- サーバーに対して構成されている接尾辞をプレビューするには、最後の列の「サフィクスのプレビュー」リンクをクリックします。
- 構成対象の別のサーバーを追加するには、「追加」をクリックして、前述のステップ6を繰り返します。
- トポロジからサーバーを削除するには、サーバー名を選択して、「削除」をクリックします。
  
  「次」をクリックします。
「グローバル管理者」ページでは、ドメイン管理者はOUDSMを使用して複数のディレクトリ・サーバー・インスタンスを管理できます。この管理者は、新しいレプリケーション・トポロジを管理するグローバル管理者です。
グローバル管理者に関する次の情報を指定します。
- グローバル管理ユーザーID: トポロジの表示および管理が行える管理者です。
- 「グローバル管理パスワード」。先ほど指定したグローバル管理者のパスワードを入力します。
- グローバル管理パスワードの確認: 確認のため、パスワードを再入力します。
「次」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、各レプリケーション・サーバーに関する次の情報が表示されます。
- 「ホスト」。レプリケーション・サーバーのホスト名は、ここでは変更できません。
- 「管理ポート」。レプリケーション・サーバーの管理ポートは、ここでは変更できません。
- レプリケーション・サーバーとして動作: サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
- 「レプリケーション・ポート」。前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
  
  ノート:
  
  未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すべてのサーバーの中の2つ以上のサーバーで使用可能なすべての接尾辞が表示されます。トポロジ内の各接尾辞がレプリケートされるかどうかを示します。ここで有効化した接尾辞は、レプリケーション・トポロジ内のすべてのサーバーにレプリケートされます。
- ドメインをレプリケーション接尾辞として動作するよう有効化するには、レプリケーションの構成セクションで、「レプリケーションに使用可能」列からドメインを選択し、右矢印をクリックして「レプリケーション用に選択済」列に移動させます。
- サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。
「次」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
- 表示された情報を変更する必要がある場合は、「戻る」をクリックします。
- サマリー情報が正しい場合は、「作成」をクリックします。

32.3.4.2 既存のトポロジへのサーバーの追加

既存のトポロジにサーバーを追加するには:

「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」ペインで、「レプリケーション構成」を選択します。

「レプリケーション構成」ページが表示されます。
レプリケーション構成ウィザードを起動するには、「構成」をクリックします。
- 現在のサーバーがすでに部分的にレプリケーション用に構成されている場合、そのサーバーは、すでに既存のトポロジの一部として存在しています。ステップ6を省略して、ステップ7に進みます。
- 現在のサーバーが部分的にレプリケーション用に構成されていない場合、「レプリケーション・オプション」ページが表示されます。ステップ6に進みます。
「レプリケーション・オプション」ページで、サーバーを追加したい既存のトポロジがありますか。を選択します。

「次」をクリックします。
接続/アイデンティティ・サーバー・ページで、既存トポロジに接続するサーバーについての次の情報が表示されます。
- 「ホスト」。現在のサーバー・ホストがすでにトポロジに含まれている場合、その名前はここでは変更できません。現在のサーバー・ホストがトポロジに含まれていない場合、トポロジ内の既存サーバーのホスト名を入力します。
- 「管理ポート」。現在のサーバー・ホストがすでにトポロジに含まれている場合、その管理ポートはここでは変更できません。現在のサーバーがトポロジに含まれていない場合、先ほど指定したホストの管理ポートを入力します。
- グローバル管理ユーザーID : グローバル管理ユーザーIDを入力します。トポロジの表示および管理が行える管理者です。このユーザーIDは、トポロジの作成時に指定したものです。
- 「グローバル管理パスワード」。先ほど指定したグローバル管理者のパスワードを入力します。
「接続」をクリックします。「サーバーのリスト」と「レプリケートされたサフィックスのリスト」が表示されます。
「サーバーのリスト」と「レプリケートされたサフィックスのリスト」で、適切なトポロジにサーバーを追加していることを確認します。

表示されている情報が正しい場合は、「次へ」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、構成する各レプリケーション・サーバーに関する次の情報が表示されます。
- 「ホスト」。レプリケーション・サーバーのホスト名は、ここでは変更できません。
- 「管理ポート」。レプリケーション・サーバーの管理ポートは、ここでは変更できません。
- レプリケーション・サーバーとして動作 : サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
- 「レプリケーション・ポート」。前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
ノート:

未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。

「次」をクリックします。
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すでにトポロジ内でレプリケーション用に構成された接尾辞を含み、トポロジに追加することを選択したすべてのサーバーが表示されます。トポロジ内の各サーバーが接尾辞をレプリケートするかどうかを示します。

サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。

「次」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
- 表示された情報を変更する必要がある場合は、「戻る」をクリックします。
- サマリー情報が正しい場合は、「適用」をクリックします。

32.3.5 「トポロジ・マネージャ」タブからのレプリケーション構成ウィザードへのアクセス

新しいトポロジを作成したり、既存のレプリケーション・トポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。

次の条件のいずれかが真の場合、「トポロジ・マネージャ」タブからレプリケーション構成ウィザードを起動できます。

レプリケーション・トポロジが存在しない。「新しいトポロジの最初からの作成」を参照してください。
レプリケーション・トポロジは存在するが、現在のサーバーがトポロジに追加されていない。「既存のレプリケーション・トポロジの管理」を参照してください。

32.3.5.1 新しいトポロジの最初からの作成

新しいトポロジを最初から作成するには:

OUDSMを起動するには、ブラウザのアドレス・フィールドに次のURLを入力します。

http://host:port/oudsm

hostは、OUDSMが実行されているホストの名前で、portはその管理サーバーのポート番号です。管理サーバーのデフォルトのポート番号は7001です。
「トポロジ・マネージャ」タブをクリックします。

「トポロジ接続」タブが表示されます。
「トポロジ接続」タブの「レプリケーション・トポロジの作成」セクションで、「作成」をクリックします。

「レプリケーション・トポロジの作成」タブが表示されます。
「サーバーの識別」ページで、構成対象である2つ以上のソース・サーバーについて、次の情報を入力します。
- 「ホスト」。完全修飾ドメイン名を使用してホスト名を入力します。
- 「管理ポート」。先ほど名前を付けたサーバーの管理ポート番号を入力します。デフォルトは4444です。
- 「管理ユーザー名」。サーバーの管理者のDNを入力します。
- 「管理者パスワード」。指定した管理者のパスワードを入力します。
(オプション)このページでは、次のことも行えます。
- サーバーに対して構成されている接尾辞をプレビューするには、最後の列の「サフィックスのプレビュー」リンクをクリックします。
- 構成対象の別のサーバーを追加するには、「追加」をクリックして、前述のステップ4を繰り返します。
- トポロジからサーバーを削除するには、サーバー名を選択して、「削除」をクリックします。
「次」をクリックします。
「グローバル管理者」ページでは、ドメイン管理者はOUDSMを使用して複数のディレクトリ・サーバー・インスタンスを管理できます。この管理者は、新しいレプリケーション・トポロジを管理するグローバル管理者です。
グローバル管理者に関する次の情報を指定します。
- グローバル管理ユーザーID: トポロジの表示および管理が行える管理者です。
- 「グローバル管理パスワード」。先ほど指定したグローバル管理者のパスワードを入力します。
- グローバル管理パスワードの確認: 確認のため、パスワードを再入力します。
「次」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、構成するレプリケーション・サーバーの情報を指定します。
- 「ホスト」。サーバー・ホスト名はここでは変更できません。
- 「管理ポート」。管理ポートはここでは変更できません。
- レプリケーション・サーバーとして動作: サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
- 「レプリケーション・ポート」。前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
ノート:

未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。

「次」をクリックします。
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すべてのサーバーの中の2つ以上で使用可能なすべての接尾辞が表示されます。トポロジ内の各接尾辞がレプリケートされるかどうかを示します。ここで有効化した接尾辞は、レプリケーション・トポロジ内のすべてのサーバーにレプリケートされます。
- ドメインをレプリケーション接尾辞として動作するよう有効化するには、レプリケーションの構成セクションで、「レプリケーションに使用可能」列からドメインを選択し、右矢印をクリックして「レプリケーション用に選択済」列に移動させます。
- サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。
  
  「次」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
- 表示された情報を変更する必要がある場合は、「戻る」をクリックします。
- サマリー情報が正しい場合は、「作成」をクリックします。

32.3.5.2 既存のレプリケーション・トポロジの管理

既存のレプリケーション・トポロジを管理するには:

OUDSMを起動するには、ブラウザのアドレス・フィールドに次のURLを入力します。

http://host:port/oudsm

hostは、OUDSMが実行されているホストの名前で、portはその管理サーバーのポート番号です。管理サーバーのデフォルトのポート番号は7001です。
「トポロジ・マネージャ」サブタブで、次の情報を入力します。
- 「ホスト」。レプリケーション・トポロジに含まれる任意のサーバーのホスト名を入力します。完全修飾ドメイン名を使用してサーバー名を使用します。
- 「管理ポート」。先ほど指定したサーバーの管理ポート番号を入力します。
- グローバル管理ユーザーID: グローバル管理ユーザーIDを入力します。トポロジの表示および管理が行える管理者です。このユーザーIDは、トポロジの作成時に指定したものです。
- 「グローバル管理パスワード」。先ほど指定したグローバル管理者のパスワードを入力します。
「接続」をクリックします。
「レプリケーション・トポロジ」ページで、トポロジについての情報を表示および管理したり、追加のサーバーをトポロジに追加できます。
- レプリケーション・トポロジにサーバーを追加するには、「サーバーの追加」をクリックします。
- トポロジ情報を自動的にリフレッシュするには、トポロジ情報を自動的にリフレッシュ・チェック・ボックスをチェック・マークが表示されるまでクリックします。トポロジ情報を手動でリフレッシュするには、最初に自動リフレッシュ機能が無効化されていることを確認し、「リフレッシュ」をクリックします。
- トポロジが自動的にリフレッシュされるまでの間隔の値を編集するには、「更新」をクリックします。
- レプリケーション・トポロジで最近実行されたタスクを表示するには、「起動されたタスク」セクションで「起動されたタスクの詳細の表示」リンクをクリックします。
「レプリケーション・サーバー」および「レプリケートされたデータ」セクションで、次を実行できます。
- ドロップダウン・フィルタ・リストを使用して、レプリケートされた接尾辞、レプリケーション・ホスト名、host:port情報またはレプリケーション・グループ名などの情報のいずれかに基づいて検索結果をフィルタします。
- レプリケーション・ポート番号を変更します。
- レプリケーションを無効化するには、無効化するレプリケーション・サーバーまたはレプリケートされた接尾辞を選択します。次に、「処理」メニューで「レプリケーションの無効化」を選択します。
レプリケーション・サーバーを別のレプリケーション・グループに割り当てるには、「レプリケーション・サーバー」セクションで「レプリケーション・グループの変更」リンクをクリックします。
サーバーにレプリケートされた接尾辞を構成するには、「レプリケートされたデータ」セクションで、最初に構成するレプリケートされた接尾辞を選択します。その後、次を実行します。
- 「信頼する/信頼しない」設定を変更するには、「信頼する/信頼しない」をクリックします。信頼できるサーバーおよび信頼できないサーバーの詳細は、「分離レプリカの理解」を参照してください。
  
  ノート:
  
  トポロジへの接続に使用されるサーバーが信頼できないサーバーの場合、「信頼する/信頼しない」ボタンが無効化されます。
- サーバーを初期化するには、「初期化」をクリックします。初期化の詳細は、「レプリケーションの初期化の理解」を参照してください。
- 事前外部初期化を開始するには、「事前外部初期化」をクリックします。事前外部初期化の詳細は、「dsreplication」および「gicadm」のpre-external-initializationオプションを参照してください。
- 事後外部初期化を開始するには、「事後外部初期化」をクリックします。事後外部初期化の詳細は、「dsreplication」および「gicadm」のpost-external-initializationオプションを参照してください。
- 履歴データをパージするには、「履歴のパージ」をクリックします。履歴データのパージの詳細は、「履歴情報をパージする方法の理解」および「履歴レプリケーション・データのパージの理解」を参照してください。
- データ・レプリケーション・グループを変更するには、「レプリケーション・グループの変更」をクリックします。レプリケーション・グループの詳細は、「レプリケーション・グループについて」を参照してください。
グローバル管理者の資格証明を変更するには、「トポロジ設定」をクリックします。次の情報を指定します。
- 「グローバル管理者ID」。トポロジへの接続やトポロジの管理を行える管理者のユーザー名を入力します。このユーザー名は、トポロジの作成時に作成されます。
- 「グローバル管理パスワード」。先ほど名前を付けた管理者のパスワードを入力します。
- グローバル管理パスワードの確認: 前述の管理者名のパスワードを再入力します。
「適用」をクリックします。

32.4 大規模なレプリケーション・トポロジの構成の理解

大規模なトポロジにおける専用レプリケーション・サーバーと専用ディレクトリ・サーバーのコンテキストの説明および専用レプリケーション・サーバーの構成方法は、これらのトピックを参照してください。

32.4.1 大規模なレプリケート・トポロジについて

特に大規模なトポロジでは、専用レプリケーション・サーバーと専用ディレクトリ・サーバーを構成する方が簡単な場合が多くあります。

ディレクトリ・サーバーを含まない専用ディレクトリ・サーバー。これらにはレプリケート対象データは格納されますが、レプリケート対象データに加えられた変更を記録した変更ログは格納されません。また、専用ディレクトリ・サーバーはレプリケーション・ポートも構成されません。
専用レプリケーション・サーバーには、レプリケーション・サーバーまたはレプリケート対象データは格納されませんが、トポロジ内の他のサーバーでレプリケート対象データに加えられた変更を記録した変更ログが格納されます。また、専用レプリケーション・サーバーはレプリケーション・ポートも構成します。

ノート:

シングル・ポイント障害を回避するために、どのトポロジにも少なくとも2つのレプリケーション・サーバーが必要です。

詳細およびサンプル・トポロジは、「ディレクトリ・サーバーを使用するデプロイメント・シナリオの理解」を参照してください。

次の図に、1台の専用レプリケーション・サーバー(レプリケーション・サーバー2)、4台の専用ディレクトリ・サーバー、およびレプリケーション・サーバーとディレクトリ・サーバーを兼ねた1台のサーバー(ホスト1)からなる大規模なレプリケーション・トポロジを示します。

図32-2 大規模なレプリケーション・トポロジ

「図32-2 大規模なレプリケーション・トポロジ」の説明

32.4.2 専用レプリケーション・サーバーの構成

専用レプリケーション・サーバーを構成するには、2つのサーバー間のレプリケーションを有効にするときに--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを指定します。

次の例では、前掲の図に示したディレクトリ・サーバーCとレプリケーション・サーバー2の間のレプリケーションを構成します。

$ dsreplication enable \
  --host1 host3 --port1 4444 --bindDN1 "cn=Directory Manager" \
  --bindPasswordFile1 pwd.txt --noReplicationServer1 \
  --host2 host4 --port2 4444 --bindDN2 "cn=Directory Manager" \
  --bindPasswordFile2 pwd.txt --onlyReplicationServer2 \
  --replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \
  --baseDN "dc=example,dc=com" -X -n

32.5 `dsconfig`によるレプリケーション構成の変更

dsconfigコマンドを使用して、レプリケーション構成のいくつかの拡張プロパティを変更できます。通常、拡張プロパティはオプションです。または、ほとんどの場合に適したデフォルト値が割り当てられています。

dsconfigの使用の一般的な情報は、「dsconfigを使用したサーバー構成の管理」を参照してください。

dsconfigは、ディレクトリ・サーバー間のレプリケーションの設定には使用できません。レプリケーションの設定は、GUIインストール・ユーティリティを使用して自動的に行うか、dsreplicationコマンドを使用して手動で行います。「OUDSMを使用したデータ・レプリケーションの構成」を参照してください。

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

32.5.1 レプリケーション・ドメイン名の取得

レプリケーション・ドメイン名はディレクトリ・サーバーによって生成されます。この名前にはベースDNと一意の数値識別子が含まれています。

構成されているレプリケーション・ドメインのリストを取得するには、list-replication-domainsサブコマンドを使用します。たとえば:

$ dsconfig -h host1 -p 4444 -D "cn=directory manager" -j pwd-file -n list-replication-domains \
   --provider-name "Multimaster Synchronization"

Replication Domain : Type    : server-id : replication-server     : base-dn
-------------------:---------:-----------:------------------------:--------------------
cn=admin data      : generic : 13981     : host1:8989, host2:8989 : cn=admin data
cn=schema          : generic : 20284     : host1:8989, host2:8989 : cn=schema
dc=example,dc=com  : generic : 26560     : host1:8989, host2:8989 : "dc=example,dc=com"

32.5.2 レプリケーション・パージ遅延の構成

レプリケーション変更データベースは、レプリケートが完了した更新またはレプリケートが完了していない更新の記録を保持しています。レプリケーション・パージ遅延はレプリケーション・サーバーのプロパティで、レプリケーション変更データベースに対して内部パージ操作を実行するまでの期間を指定します。

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

32.5.2.1 レプリケーション変更記録のパージ動作

パージ遅延の期間を過ぎた変更記録は、すでに適用されたかどうかに関係なく、レプリケーション変更データベースから削除されます。デフォルトのパージ遅延は100時間です。レプリケーション変更データベースのバックアップ間隔がこのパージ遅延の期間より短いと、変更データベースがバックアップされる前に変更記録がクリアされてしまいます。したがって、バックアップからデータをリストアしても、変更記録が失われる可能性があります。

32.5.2.2 レプリケーション・パージ遅延の変更

レプリケーション・パージ遅延を変更するには:

レプリケーション・パージ遅延の現在値を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --property replication-purge-delay

Property                : Value(s)
------------------------:---------
replication-purge-delay : 1 d

パージ遅延を変更します。

次のコマンドは、パージ遅延を1週間に変更します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" \
  --set replication-purge-delay:1w

32.5.3 ウィンドウ・サイズの構成

ウィンドウ・サイズはレプリケーション・サーバーのプロパティで、レプリケーション・サーバーがディレクトリ・サーバーからの確認応答を待たずにディレクトリ・サーバーに送信できる変更リクエストの数を指定します。

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

32.5.3.1 ウィンドウ・サイズについて

ウィンドウ・サイズは、ディレクトリ・サーバーからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、素早く連続して多くのメッセージを送信する方が効率的です。適切なウィンドウ・サイズを使用することで、レプリケーション・サーバーが確認応答の到着を待つために費やす時間を排除できます。デフォルトのウィンドウ・サイズは100です。一部のディレクトリ・サーバーで変更のレプリケーションが遅れていることに気付いた場合は、他の調整を行う前に、ウィンドウ・サイズの値を大きくしてレプリケーション・パフォーマンスをもう一度確認してください。

32.5.3.2 ウィンドウ・サイズの変更

ウィンドウ・サイズを変更するには:

ウィンドウ・サイズの現在値を表示します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  get-replication-server-prop --provider-name "Multimaster Synchronization" \
   --advanced --property window-size

Property    : Value(s)
------------:---------
window-size : 100

ウィンドウ・サイズを変更します。

次のコマンドは、ウィンドウ・サイズを200に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --set window-size:200

32.5.4 初期化ウィンドウ・サイズの構成

レプリケート対象トポロジ内でのデータ・インポート時に、インポート側のサーバーが遅すぎてエクスポート側のサーバーから送信されるデータについていけないことがあります。このような場合、インポート側サーバーはインポートを妨げるだけでなく、エクスポート側サーバーによる他のレプリケーション変更記録の伝播まで妨げるおそれがあります。

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

32.5.4.1 初期化ウィンドウ・サイズについて

初期化ウィンドウ・サイズを使用することで、エクスポート側サーバーは最も遅いインポート側サーバーからの確認応答を検出し、その遅いインポート側サーバーが受信可能な状態のときのみデータをレプリケーション・ネットワーク上に送信することが可能になります。

デフォルトでは、初期化ウィンドウ・サイズは100です。トポロジ内に遅いサーバーがない場合は、初期化ウィンドウ・サイズを大きくできます。これにより、エクスポート側サーバーがより多くの更新を、確認応答を待たずに送信できるようになります。トポロジ内に非常に遅いサーバーがある場合は、初期化ウィンドウ・サイズを小さくすることで、そのサーバーがレプリケーションを妨げないようにできます。

32.5.4.2 初期化ウィンドウ・サイズの変更

初期化ウィンドウ・サイズを変更するには:

初期化ウィンドウ・サイズの現在値を表示します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  get-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name dc=example,dc=com --advanced --property initialization-window-size 
Property                   : Value(s)
---------------------------:---------
initialization-window-size : 100

初期化ウィンドウ・サイズを変更します。

次のコマンドは、初期化ウィンドウ・サイズを50に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name dc=example,dc=com --set initialization-window-size:50

32.5.5 ハートビート間隔の構成

ハートビート間隔はレプリケーション・ドメインのプロパティで、レプリケーション・ドメインがレプリケーション・サーバーと通信する間隔を指定します。レプリケーション・ドメインは、レプリケーション・サーバーからこの間隔で定期的にハートビートが届くのを待ちます。ハートビートが受信されない場合、ドメインはその接続を閉じ、トポロジ内の別のレプリケーション・サーバーに接続します。

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

32.5.5.1 ハートビート間隔について

デフォルトのハートビート間隔は10秒です。応答が遅いWANまたはネットワーク上でレプリケーションを実行している場合は、ハートビート間隔を長くできます。また、次のようなエラーがログに記録されている場合は、おそらくハートビート間隔を長くする必要があります。

[26/May/2011:16:32:50 +0200] category=SYNC severity=NOTICE msgID=15138913
 msg=Replication Heartbeat Monitor on RS rserver/192.157.197.62:8989 30382 for 
 dc=example,dc=com in DS 10879 is closing the session because it could not
 detect a heartbeat

ハートビート間隔はJVMの設定に影響されます。ハートビート間隔をデフォルトより短くする必要がある場合は、必ずJVMの-XX:+UseConcMarkSweepGCオプションを設定して、ガベージ・コレクション中の一時停止時間を短くしてください。詳細は、『Oracle Unified Directoryのインストール』のJVM、Javaオプションおよびデータベース・キャッシュの構成に関する項を参照してください。

32.5.5.2 ハートビート間隔の変更

ハートビート間隔を変更するには:

ハートビート間隔の現在値を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 15853)" --advanced \
  --property heartbeat-interval 
Property           : Value(s)
-------------------:---------
heartbeat-interval : 10 s

ハートビート間隔を変更します。

次のコマンドは、ハートビート間隔を5秒に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 15853)" --set heartbeat-interval:5s

32.5.6 分離ポリシーの変更

分離ポリシーはレプリケーション・ドメインのプロパティです。このプロパティは、レプリケーションが構成されているのに、更新の受信時にレプリケーション・サーバーが1つも起動および実行されていない場合のディレクトリ・サーバーの動作を指定します。この場合のディレクトリ・サーバーのデフォルト動作は、すべての更新を拒否するというものです。

分離ポリシーを変更するには:

現在の分離ポリシーを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
 get-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 15853)" \
  --advanced --property isolation-policy -n

Property         : Value(s)
-----------------:-------------------
isolation-policy : reject-all-updates

分離ポリシーを変更します。

次のコマンドは、このような場合にディレクトリ・サーバーがすべての更新を受け入れるように指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 15853)" \
  --set isolation-policy:accept-all-updates -n

32.5.7 暗号化レプリケーションの構成

デフォルトでは、レプリケーションの通信は暗号化されません。暗号化を有効にするには、dsconfigコマンドを使用して暗号化マネージャのプロパティを設定します。

次のコマンドは、レプリケーションの通信を暗号化するように指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  set-crypto-manager-prop --set ssl-encryption:true

32.5.8 レプリケーション・グループの構成

レプリケーション・グループに関するコンテキストに応じた説明と、レプリケーション・グループを構成する手順は、これらのトピックを参照してください。

32.5.8.1 レプリケーション・グループについて

レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。

レプリケーション・グループの構成は、同じグループに所属させる個々のディレクトリ・サーバーおよびレプリケーション・サーバーで行います。ディレクトリ・サーバーでは、レプリケート対象ドメインごとにレプリケーション・グループを構成します。レプリケーション・サーバーでは、レプリケーション・サーバー全体に対してグループを構成します。ディレクトリ・サーバーにおけるレプリケーション・グループの設計と実装の詳細は、「レプリケーション・グループについて」を参照してください。

ノート:

レプリケーション・グループの構成を変更すると、保証レプリケーションに影響します。詳細は、「保証レプリケーションの理解」を参照してください。

32.5.8.2 レプリケーション・グループの構成

レプリケーション・グループを構成するには、それぞれのレプリケート対象ドメインとレプリケーション・サーバーに同じグループIDを割り当てます。次の例では、レプリケート対象ドメインdc=example,dc=comに対してレプリケーション・グループ(1)を構成します。

このグループに所属させる各ディレクトリ・サーバーで、ドメインdc=example,dc=comに対してグループIDを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --set group-id:1

このグループに所属させる各レプリケーション・サーバーで、グループIDを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --set group-id:1

32.5.9 保証レプリケーションの構成

保証レプリケーションは、通常のレプリケーションの動作の同期性を高める方法です。

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

32.5.9.1 保証レプリケーション構成について

ほとんどのデプロイメント・シナリオでは、ゆるやかな一貫性を持つマルチマスター・レプリケーション・モデルで十分です。しかし、シナリオによっては、レプリカ間のより厳格な一貫性が必要とされる場合もあります。このような場合は、保証レプリケーションを構成できます。保証レプリケーションには、次の利点があります:

データの高可用性。サーバーが変更を受信した直後にクラッシュした場合、変更がトポロジ内の他のサーバーにレプリケートされる前に失われるおそれがあります。保証レプリケーションでは、確認応答がクライアント・アプリケーションへ送信される前に、変更がトポロジ内の他のサーバーにリプレイされ、サーバーがクラッシュした場合にデータを失うリスクが最小限になります。
即時のデータ可用性。アプリケーションによっては、変更が行われた直後にその変更がトポロジ内の他のサーバーで使用できるようになることが必要な場合があります。

保証レプリケーションはレプリケーション・プロトコルの拡張であり、レプリケート対象ドメイン単位で構成されます。詳細は、「レプリケーション・ドメイン名の取得」を参照してください。

保証レプリケーションは、同期レプリケーションとは異なります。つまり、トポロジ内のすべてのサーバーで同時に変更が行われるわけではありません。ただし、LDAPクライアントに関するかぎり、保証レプリケーションは同期レプリケーションの機能をある程度まで模倣します。変更がトポロジ内の他のサーバーに伝播されるまで、クライアント・アプリケーションへの確認応答を遅らせることによって、これを実現しています。

ノート:

保証レプリケーションは、レプリケーション・グループに依存しています。1つの保証レプリケーション構成で連動するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーが同じレプリケーション・グループに属している必要があります。

保証レプリケーションには次の2つの動作モードがあります:

セーフ・データ・モード。更新が正常に完了したという確認応答をクライアントが受信する前に、定義した数のレプリケーション・サーバーへ更新を伝播させる必要があります。

伝播が必須であるレプリケーション・サーバーの数によって安全データ・レベルが既定されます。安全データ・レベルが高ければ高いほど、全体のデータ可用性が高まります。
セーフ読取りモード。更新が正常に完了したという確認応答をクライアントが受信する前に、トポロジ内のすべてのディレクトリ・サーバーへ更新を伝播させる必要があります。

安全データ・モードでも安全読取りモードでも、トポロジ内のいくつかのサーバーが使用不可である場合にLDAPクライアント・コールがハングしないように、タイムアウト間隔を設定できます。

各ディレクトリ・サーバーでは、ディレクトリ・サーバーがレプリケーション・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、LDAPクライアント・コールは即座に復帰し、このイベントを追跡するためのメッセージがレプリケーション・ログに書き込まれます。
各レプリケーション・サーバーでは、レプリケーション・サーバーがピアのレプリケーション・サーバーまたは別のディレクトリ・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、開始サーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)に返される確認応答メッセージに、タイムアウトを示すメッセージが挿入されます。すると、開始ディレクトリ・サーバーは、その更新に対してタイムアウトが発生したというメッセージをログに書き込みます。

ノート:

ほとんどのデプロイメントでは、デフォルトのタイムアウトで問題ありません。ディレクトリ・サーバーは2秒、レプリケーション・サーバーは1秒です。タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。更新がフル・パスを経由して目的のサーバーに届くまでにかかる時間を見越して、タイムアウト値に反映させる必要があります。

ディレクトリ・サーバーのタイムアウト値は、レプリケーション・サーバーの値より必ず大きくしてください。たとえば: DS1(タイムアウト2秒)→RS1(タイムアウト1秒)→RS2(タイムアウト1秒)→DS2

保証レプリケーションのメカニズムと様々な構成オプションの詳細は、「保証レプリケーションの理解」を参照してください。

32.5.9.2 セーフ・データ・モードの保証レプリケーションの構成

この手順では、トポロジに対して安全データ・モードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。

トポロジ内の各ディレクトリ・サーバーで次の操作を行います:
1. 保証レプリケーションのモードを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --set assured-type:safe-data
```
2. 安全データ・レベルを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --set assured-sd-level:2
```
  setupまたはdsreplicationを使用してレプリケーションを構成した場合は、レプリケーション・サーバーおよびディレクトリ・サーバーが同一の仮想マシン上に存在します。この場合は、安全データ・レベルを2以上に設定してください。
3. 保証レプリケーションのタイムアウトを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced\
  --set assured-timeout:5s
```
  タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
4. ディレクトリ・サーバーのグループIDを確認します。
  
  これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、「レプリケーション・グループの構成」を参照してください。
5. 保証レプリケーションの現在の構成を表示します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --property assured-type --property assured-sd-level --property assured-timeout

Property         : Value(s)
-----------------:------------
assured-sd-level : 2
assured-timeout  : 5 s
assured-type     : safe-data
```
トポロジ内の各レプリケーション・サーバーで次の操作を行います:
1. 保証レプリケーションの現在の構成を表示します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --property assured-timeout --property group-id

Property                  : Value(s)
--------------------------:---------
assured-timeout           : 1 s
group-id                  : 1
```
2. 保証レプリケーションのタイムアウトを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --set assured-timeout:5s
```
  タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
3. レプリケーション・サーバーのグループIDを確認します。
  
  これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、「レプリケーション・グループの構成」を参照してください

32.5.9.3 セーフ読取りモードの保証レプリケーションの構成

保証レプリケーションは、レプリケート対象ドメインごとに構成します。この手順では、トポロジに対して安全読取りモードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。

トポロジ内の各ディレクトリ・サーバーで次の操作を行います:
1. 保証レプリケーションのモードを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --set assured-type:safe-read
```
2. 保証レプリケーションのタイムアウトを設定します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --set assured-timeout:5s
```
  タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
3. ディレクトリ・サーバーのグループIDを確認します。
  
  これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、「保証レプリケーションの理解」を参照してください。
4. 保証レプリケーションの現在の構成を表示します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-domain-prop \
  --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" --advanced \
  --property assured-type --property assured-timeout --property group-id

Property         : Value(s)
-----------------:------------
assured-timeout  : 5 s
assured-type     : safe-read
group-id         : 1
```
トポロジ内の各レプリケーション・サーバーで次の操作を行います:
1. 保証レプリケーションの現在の構成を表示します。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  get-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --property assured-timeout --property degraded-status-threshold \
  --property group-id

Property                  : Value(s)
--------------------------:---------
assured-timeout           : 1 s
degraded-status-threshold : 5000
group-id                  : 1
```
2. 保証レプリケーションのタイムアウトを設定します。
  
  タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --set assured-timeout:5s
```
3. 機能低下ステータスのしきい値を設定します。
  
  機能低下ステータスのしきい値では、そのディレクトリ・サーバーに対するレプリケーション・サーバーのキューに入っている更新の数に基づいて、サーバーを「遅すぎる」と判断する段階を定義します。詳細は、「低下ステータスとは」を参照してください。
  
  ログにタイムアウトが記録されていないかぎり、この値は調整しないでください。
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --advanced \
  --set degraded-status-threshold:2000
```
4. レプリケーション・サーバーのグループIDを確認します。
  
  これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、「保証レプリケーションの理解」を参照してください。

32.5.10 部分レプリケーションの構成

次のトピックでは、トポロジ内の1つ以上のサーバーで部分レプリケーションを構成する手順について説明します。

部分レプリケーション・メカニズムのアーキテクチャの詳細は、「部分レプリケーションの概要」を参照してください。

32.5.10.1 部分レプリケーション構成について

部分レプリケーションでは、ディレクトリ・データの特定部分をトポロジ内の他のレプリカにレプリケートできます。この機能は、次のシナリオで特に有効です:

ディスク領域が限られている場合。レプリケートするデータを限定することで、特定のレプリカで必要とされるディスク領域の量を大幅に低減できます。特に、データ量が大きいjpeg写真などの属性のレプリケーションを制限すると効果的です。
セキュリティ上の問題。ユーザー・パスワードなどのデータは機密性が高く、一部のレプリカでは不要なことがあります。特に、それらのレプリカで不正アクセスの危険性があるような場合です。

部分レプリケーションの構成は、部分データを受け取るディレクトリ・サーバー上で、属性ベースで行います。次の図を参照してください:

$fractional-repl1.tifの説明が続きます$
図fractional-repl1.tifの説明

ディレクトリ・サーバーBで部分レプリケーションが構成されています。ldapmodify操作がディレクトリ・サーバーAに送信されます。この操作全体がレプリケーション・サーバー1、レプリケーション・サーバー2、ディレクトリ・サーバーBの順に転送されていきます。この操作がディレクトリ・サーバーBでレプリケートされるとき、このサーバーの部分レプリケーション構成に基づいて、操作の一部の属性が排除されます。

部分レプリカは、クライアント・アプリケーションから直接書込み可能です。ただし、禁止された属性を含む追加操作や変更操作が部分レプリカに対して試行された場合、その操作は拒否され、サーバーが「実行要求を拒否」エラーを返します。

部分レプリケーションは、次の2つのうちいずれかのモードで構成できます。

排他モード。このモードでは、fractional-excludeという複数値属性を使用して指定した属性を、受信したLDAP追加操作または変更操作から排除します。

除外する属性は、オブジェクト・クラスのオプション属性であることが必要です。
包含モード。このモードでは、fractional-includeという複数値属性を使用して指定した属性のみを、受信したLDAP追加操作または変更操作から受け入れます。

その他の属性はすべて(オブジェクト・クラスの必須属性を除き)、サーバー上でレプリケートされる変更から削除されます。

この2つのモードは同時には使用できません。つまり、どちらか一方のモードの属性のみをドメイン構成に追加できます。

部分レプリケーションはレプリケート対象ドメイン単位で構成します(「レプリケーション・ドメイン名の取得」を参照)。部分ドメインは、特定の属性がそのドメインにまったく存在しないことを意味します。これらの属性は操作のリプレイ時に排除されるだけでなく、ドメインの既存データ自体にも存在しません。

レプリケート対象トポロジ全体でデータの一貫性を確保するためには、特定のデータ・セットが部分的であるかどうかを判断する必要があります。したがって、新しい部分ドメインを構成する作業には、そのドメインに禁止の属性が存在しないことと、そのドメインが部分ドメインとして認識可能であることを確認するステップが伴います。詳細は、「部分ドメインの構成および初期化」を参照してください。

ドメインの部分レプリケーションを構成するには、次のようにdsconfigコマンドを使用します。

32.5.10.2 排他部分レプリケーションの構成

次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更からphoto属性とjpegPhoto属性を除外するようにレプリカを構成します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-exclude:inetOrgPerson:photo,jpegPhoto

オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-exclude:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.7, \
  0.9.2342.19200300.100.1.60

オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、除外する属性のリストに追加します:

$ dsconfig set-replication-domain-prop ... 
  --set fractional-exclude:*:jpegPhoto,*:0.9.2342.19200300.100.1.60

この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。

オブジェクト・クラスを問わず、すべてのエントリの作成または変更からphoto属性とjpegPhoto属性を削除するように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。たとえば:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-exclude:*:photo,jpegPhoto

32.5.10.3 包含部分レプリケーションの構成

次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更にuid属性とemployeeNumber属性のみを含めるようにレプリケーションを構成します。その他の属性は変更において、オブジェクト・クラスの必須属性を除きすべて無視されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-include:inetOrgPerson:uid,employeeNumber

オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-include:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.1, \
  2.16.840.1.113730.3.1.3

オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、含める属性のリストに追加します:

$ dsconfig set-replication-domain-prop ... 
  --set fractional-include:*:jpegPhoto,*:0.9.2342.19200300.100.1.60

この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。

オブジェクト・クラスを問わず、すべてのエントリの作成または変更に特定の属性を含めるように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。次の例では、すべてのエントリに対する作成操作または変更操作にdescription属性のみを含めます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name "dc=example,dc=com (domain 10233)" \
  --set fractional-include:*:description

32.5.10.4 部分ドメインの構成および初期化

新しい部分ドメインを初期化するには:

前述の2つの項の説明に従って、排他または包含モードの部分レプリケーションを構成します。

この時点で、ドメインのステータスがbad generation IDになります。詳細は、「レプリケーション・ステータスの概要」を参照してください。

このステータスは、データがトポロジ内の他のサーバーと同期されるまで、このドメインでの変更がすべてブロックされることを意味します。
トポロジ内の他のサーバーの1つから新しいデータ・セットをインポートします。

新しいデータ・セットをオンラインでインポートするには、dsreplication initializeを使用するか、import-ldifをオンライン・モードまたはオフライン・モードで使用します。データのインポート元にするサーバーは、完全なレプリカである(つまり、部分レプリカではない)か、またはデータのインポート先のサーバーと同じ部分構成が設定されている必要があります。インポート時には、前述のステップで設定した部分構成に従って、すべてのエントリがフィルタリングされます。

データ・セットをインポートする方法の詳細は、「単一のレプリケート対象サーバーの初期化」と「データのインポートおよびエクスポート」を参照してください。
データ・インポート後、ドメインのステータスがnormalに戻ります。

詳細は、「レプリケーション・ステータスの概要」を参照してください。

これで、ドメインはローカルLDAP操作やトポロジ内の他のサーバーとの同期操作から新規エントリの受入れが可能になりました。ドメイン内のデータに禁止の属性は存在しません。

32.5.11 レプリケーション・ステータスの構成

レプリケート対象トポロジ内の各レプリケート対象ドメインには、トポロジ内での接続状態や、トポロジ内で発生した変更の反映状況に応じて特定のレプリケーション・ステータスが設定されます。

詳細は、「レプリケーション・ステータスの概要」を参照してください。

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

32.5.11.1 レプリケーション・ステータスにある低下ステータスのしきい値パラメータの構成について

レプリケーション・ステータスは、サーバーがレプリケート対象トポロジ内でどの程度最新の状態に保たれているかに応じて自動的に生成されます。構成可能なパラメータは機能低下ステータスしきい値のみです。これは、このレプリケーション・サーバーに接続されているディレクトリ・サーバーのすべてのドメインに対してレプリケーション・サーバーのキューで許容される変更の最大数を定義します。特定のディレクトリ・サーバーに対してこの数に達すると、そのサーバーに機能低下ステータスが割り当てられます。機能低下ステータスは、変更数がこの値を下回るまで維持されます。

ノート:

機能低下ステータスしきい値のデフォルト値は、ほとんどのデプロイメントに適しています。保証レプリケーションが構成されている場合で、ログに複数のタイムアウト・メッセージが記録されているときのみ、この値を変更します。

32.5.11.2 低下ステータスのしきい値の構成

このしきい値で定義されているデフォルトの変更数は5000です。次の例では、待機時間が長いネットワークを考慮して、しきい値を6000に設定します。

レプリケーション・サーバーでdsconfigを使用して機能低下ステータスしきい値を設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  set-replication-server-prop --provider-name "Multimaster Synchronization" \
  --set degraded-status-threshold:6000

32.5.12 レプリケーション・サーバーの重みの構成

複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。

トポロジ内の各レプリケーション・サーバーに接続するディレクトリ・サーバーの数を、レプリケーション・サーバーが稼働しているマシンの相対的な能力に応じて指定できます。詳細は、「レプリケーション・サーバーのロード・バランシングの理解」を参照してください。

レプリケーション・サーバーの重みを構成するには、次のようにdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  set-replication-server-prop \
  --provider-name "Multimaster Synchronization" --set weight:2

デフォルトでは、トポロジ内の各レプリケーション・サーバーの重みは1です。

32.6 データによるレプリケート対象サーバーの初期化

gicadmコマンドを使用することで、レプリケート対象サーバーを初期化できます。このコマンドでは、SSL経由で管理コネクタを介してサーバー構成にアクセスします。

次のトピックでは、レプリケート対象サーバーをデータで初期化する方法について説明します。

ノート:

詳細は、「サーバーへの管理トラフィックの管理」および「gicadm」を参照してください。

また、この項では、「スタンドアロン・ディレクトリ・サーバーへのデータの移入」に記載されている情報を参照します。先に進む前に、この項を参照してください。

32.6.1 単一のレプリケート対象サーバーの初期化

トポロジ内の単一のディレクトリ・サーバーを初期化する最も簡単な方法は、dsreplicationコマンドを使用して、トポロジ内の別のディレクトリ・サーバーからデータをコピーする方法です。このコマンドを使用するには、コピー元のサーバーとコピー先のサーバー同士のレプリケーションが有効になっている必要があります。このコマンドは、コピー先サーバーの指定したベースDNの下にあるすべてのデータをコピー元サーバーからのデータに置き換えます。

たとえば、次のコマンドはhost2のベースDN "dc=example,dc=com"をhost1のデータで初期化します。

$ dsreplication initialize --baseDN "dc=example,dc=com" \
  --adminUID admin --adminPasswordFile pwd.txt \
  --hostSource host1 --portSource 4444 \
  --hostDestination host2 --portDestination 4444 --trustAll

32.6.2 新しいレプリケート対象トポロジの初期化

新しいレプリケート・トポロジでは、単一のディレクトリ・サーバーまたはすべてのディレクトリ・サーバーを同じデータで個別に初期化できます。

「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、すべてのディレクトリ・サーバーを同じデータで個別に初期化します。すべてのディレクトリ・サーバーをデータで初期化したら、サーバー間のレプリケーションを有効にします。
「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、単一のディレクトリ・サーバーを初期化します。すべてのディレクトリ・サーバーに対してレプリケーションを有効にし、dsreplication intialize-allコマンドを使用して残りのすべてのサーバーを同時に初期化します。このコマンドはソース・サーバーの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。

たとえば、次のコマンドはすべてのディレクトリ・サーバーをhost1上のコンテンツで初期化します。
```
$ dsreplication initialize-all --hostname localhost --port 4444 --trustAll \
  --baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt
```

32.6.3 既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加

既存のレプリケート対象トポロジにディレクトリ・サーバーを追加する場合、トポロジ内の既存のディレクトリ・サーバーと同じデータ生成を新しいサーバーに移入する必要があります。データ生成とは、レプリケーション・ドメインのルート・エントリに格納されているIDです。データ生成が存在しない場合、レプリケーション・メカニズムによってデータ生成が計算され格納されます。

新しいディレクトリ・サーバーがトポロジ内の他のサーバーと同じデータ生成を保持するようにするには、次のいずれかの方法でディレクトリ・サーバーにデータを移入します:

他のディレクトリ・サーバーの移入に使用した同じオリジナルLDIFファイル、バックアップ・ファイルまたはバイナリ・コピーを使用します。
トポロジ内の別のディレクトリ・サーバーからのエクスポート、バックアップまたはバイナリ・コピーを使用します。

GUIインストールを使用して新しいディレクトリ・サーバーをインストールする場合は、そのサーバーをレプリケート対象トポロジのメンバーにすることを指定すれば、自動的に適切なデータ生成を使用してサーバーが初期化されます。

GUIインストールを使用せずにディレクトリ・サーバーをインストールし、dsreplicationコマンドを使用してレプリケーションを有効にする場合は、前述の項で説明したいずれかの方法により手動でサーバーを初期化する必要があります。

トポロジ内のディレクトリ・サーバーにトポロジ内の他のサーバーと同じデータ生成が格納されていない場合、そのディレクトリ・サーバーとのデータ・レプリケーションはできません。ただし、そのディレクトリ・サーバーもトポロジとの接続は維持されており、レプリケーション・プロトコルによる初期化が可能です。このディレクトリ・サーバー上のレプリケーションは、ダウングレードした状態にあるといいます。

適切なデータ生成を持つディレクトリ・サーバーが既存のトポロジに追加されると、トポロジ内の最初のディレクトリ・サーバーがデータで初期化された時点以降に発生したすべての変更がレプリケーション・メカニズムによって自動的にリプレイされます。この動作より、新しいディレクトリ・サーバーがトポロジ内の他のサーバーと確実に同期されます。

32.6.4 既存のレプリケート対象トポロジにあるデータ・セットの変更

データ・セットを変更するには、完全に新規のデータ・セットをトポロジ内のすべてのディレクトリ・サーバーにインポートします。

データ・セットが変更される際、2つのタスクが実行されます:

新しいデータがトポロジ内の各ディレクトリ・サーバーに適用されます。
レプリケーション・サーバーに格納されている変更がすべてクリアされます。このタスクには、各ディレクトリ・サーバー上のデータ生成をリセットして新しいデータ生成が使用されるようにする操作も含まれます。

dsreplication initializeコマンドを使用してデータ・セットを変更すると、これらのタスクの両方が自動的に実行されます。ただし、import-ldifコマンドまたはバイナリ・コピー方式でデータ・セットを変更する場合は、これらのタスクを手動で行う必要があります。

import-ldif、バイナリ・コピーまたはrestoreを使用してデータ・セットを変更するには、次のようにします。

dsreplication pre-external-initializationコマンドを実行して、ディレクトリ・サーバーから生成IDをクリアします。
このコマンドは、トポロジ内のいずれかのディレクトリ・サーバーで実行するだけで十分です。トポロジ内のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内の全サーバーの初期化を準備します:
```
$ dsreplication pre-external-initialization -h host1 -p 4444 -X \
  -b dc=example,dc=com -I admin -j pwd-file

Establishing connections and reading configuration ..... Done.

pre-external-initialization should only be used if you are going to initialize
all the replicated servers. If it is not the case (for instance you are going
to recover only a server or you are in the process of adding a new server to 
the replication topology), the subcommand must not be executed.
Do you want to continue? (yes / no) [yes]:
```
import-ldif、binary copyまたはrestoreを使用して、トポロジ内のすべてのディレクトリ・サーバーをデータで初期化します。import-ldif、binary copyまたはbackup-restoreのいずれかを使用してディレクトリ・サーバーのデータを初期化する場合は、次のchangelogの動作を確認できます。
- pre-external-initializationコマンドを使用すると、changelogがリセットされ、pre-external-initializationコマンドを実行する前にchangelogDBに存在している値がクリアされます。したがって、import-ldif コマンドまたはbinary copy (<instance>/OUD/dbをコピーする場合のみ)メカニズムを使用すると、pre-external-initializationコマンドを実行する前に存在していたchangelogDBは復元されません。
- changelogDBは、pre-external-initializationコマンドを実行する前に、backupコマンドを使用して、完全バックアップが実行された場合にのみ復元されます。完全なバックアップは、restoreコマンドと、バックアップ・ディレクトリに存在するreplicationChangesを使用して復元されます。
  
  ノート:
  restoreコマンドが実行され、replicationChangesが復元されない場合、バックアップchangelogは失われます。
dsreplication post-external-initializationコマンドを実行して生成IDをリセットします。
このコマンドは、トポロジ内のいずれかのディレクトリ・サーバーで実行するだけで十分です。他のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内のすべてのディレクトリ・サーバーの生成IDを初期化の後にリセットします:
```
$ dsreplication post-external-initialization -h localhost \ 
  -p 4444 -b dc=example,dc=com -I admin -j pwd-file -X 
Updating replication information on base DN dc=example,dc=com ..... Done. 
Post initialization procedure completed successfully. 
```

32.6.5 既存のレプリケート対象トポロジへのデータの追加

すでに大量のエントリが含まれている既存のレプリケート対象トポロジに大量のエントリをインポートする最も簡単な方法は、import-ldifコマンドに-aオプションまたは--appendオプションを指定して使用する方法です。

import-ldifコマンドを使用してデータをインポートする場合、レプリケート対象データが自動的にはレプリケートされません。このため、import-ldif --appendをトポロジ内のすべてのディレクトリ・サーバーで実行する必要があります。この戦略では、ディレクトリ・サービスを停止せずにデータをインポートできます。

また、トポロジ内の単一のディレクトリ・サーバーにデータをインポートしてから、dsreplication initialize-allコマンドを使用することもできます。ただし、この戦略ではディレクトリ・サービスが一定期間、使用不可になります。

32.7 外部変更ログの使用

外部変更ログ(ECL)は、ディレクトリ・サーバー・データベース内で発生したすべての変更を公開します。特に、LDAPディレクトリを他のサブシステムと同期させる場合に便利です。

外部変更ログはレプリケーション変更ログからオンラインで構築され、その保管に追加のデータベースは使用されません。通常のJEBバックエンドではないため、索引の構成は不要です。

次のトピックでは、ディレクトリ・サービスで外部変更ログを有効にする方法と、外部変更ログにアクセスできるようにクライアント・アプリケーションを構成する方法について説明します。

32.7.1 外部変更ログの有効化

ディレクトリ・サーバーとレプリケーション・サーバーの両方を含むすべてのサーバー・インスタンスでは、外部変更ログ(ECL)がデフォルトで使用できます。外部変更ログは、ディレクトリ・サーバーがインストール時にレプリケート・トポロジの一部として構成されるか、またはレプリケーションがインストール後に構成された場合に有効化されます。

専用ディレクトリサーバーまたは専用レプリケーション・サーバーのいずれかとして構成されたサーバー・インスタンスでは、外部変更ログがデフォルトでは使用できません(「大規模なレプリケーション・トポロジの構成の理解」を参照)。

次のいずれかの方法でレプリケーションを構成すると、外部変更ログが有効になります:

インストール時にレプリケート対象トポロジのメンバーとしてディレクトリ・サーバーを構成する方法。詳細は、『Oracle Unified Directoryのインストール』のインストール時のレプリケーションの設定に関する項を参照してください。
インストール後にdsreplicationコマンドを使用してレプリケーションを構成する方法。詳細は、「OUDSMを使用したデータ・レプリケーションの構成」を参照してください。

ノート:

--onlyReplicationServerオプションまたは--noReplicationServerオプションを指定してレプリケーションを構成した場合は、外部変更ログが使用できません。

外部変更ログの機能はレプリケーション・メカニズムに基づいていますが、クライアント・アプリケーションによっては、レプリケート対象トポロジの外側のローカル・サーバー上にある外部変更ログ・コンテンツを必要とするものもあります。ローカル・サーバーで特定のベースDNに対する外部変更ログを有効にするには、次のコマンドを実行します:

$ dsreplication enable-changelog -h localhost -p 4444 -D "cn=directory manager" \
  -j pwd-file -r 8989 -b dc=example,dc=com -X -n

外部変更ログを構成するには、スタンドアロン・サーバーでもレプリケーション・ポート(-r)が必要ですが、これは外部変更ログがレプリケーション・メカニズムに依存しているためです。レプリケーション・ポートを指定する必要があるのは、そのサーバーで変更ログ(またはレプリケーション)があらかじめ構成されていない場合のみです。レプリケーション・ポートのデフォルト値は8989です。

ディレクトリ・サーバー・インスタンス上で外部変更ログが構成されていることを確認するには、次の検索コマンドを実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
  -s base -b "" "objectclass=*" namingContexts
dn:  
namingContexts: cn=changelog 
namingContexts: dc=Europe,dc=com 
namingContexts: dc=us,dc=com

32.7.2 外部変更ログのAPIについて

外部変更ログは、2つの個別の操作モードを有効にする2つのAPIをサポートしています。

2つの個別の操作モードは、次のとおりです。

Cookieモード。外部変更ログへのアクセスには、このAPIを使用することをお薦めします。

Cookieモードでは、クライアント・アプリケーションがサーバーへのリクエストで外部変更ログの交換制御を提供します。このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフト(http://tools.ietf.org/html/draft-good-ldap-changelog-04)と互換性がありません。
ドラフト互換モード。このモードは、LDAP変更ログ・ドラフトに依存する既存のアプリケーションでのみ使用してください。

このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフトと互換性があります。

パフォーマンスの向上および簡素化のために、クライアント・アプリケーションを移植してCookieモードを使用してください。詳細は、「他の変更ログに依存するアプリケーションの移植」を参照してください。

32.7.3 クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作

外部変更ログのエントリには、それぞれCookieが関連付けられています。クライアント・アプリケーションは、検索リクエストを送信するとき、(前回の検索の)外部変更ログから読み取った最後のメッセージのCookieまたは空の値のどちらかを提供します。サーバーは、そのCookieに関連付けられた外部変更ログ・エントリを返します。

各エントリがそれぞれに関連付けられたCookieとともに返されます。アプリケーションは接続を切断すると、受信した最後のCookieを格納し、このCookieを次の検索リクエストとともにサーバーへ送信します。

この外部変更ログCookieの送信を次の図に示します。

図external-changelog1.pngの説明

Cookieのコンテンツは、クライアント・アプリケーションのための公開インタフェースではありません。クライアント・アプリケーションはCookieをリクエスト制御として送信し、サーバーはCookieをレスポンス制御として送信します。

外部変更ログのCookie制御は、1.3.6.1.4.1.26027.1.5.4のOIDを持ちます。アプリケーションから提供されたCookieが破損しているとサーバーが判断した場合、リクエストが却下されます。また、このCookieをアプリケーションに送信した後に外部変更ログの構成が変更されたとサーバーが判断した場合や、外部変更ログがパージされており、格納されている最も古い変更がCookieの値より新しいとサーバーが判断した場合も、リクエストは却下されます。この場合、外部アプリケーションの完全な再同期を推奨する追加情報が返されます。

ノート:

サーバーがレプリケーション・トポロジから切断され、接続中のクライアントからの変更を処理した場合は、収束を保証できません。

次のリクエストとレスポンスの例で、クライアント・アプリケーションがどのように外部変更ログを使用して検索し、どのように外部変更ログが応答するかを示します。

リクエスト1

外部変更ログの読取りを開始するために、クライアントがcn=changelogに対する最初の検索リクエストを送信します。外部変更ログのCookie制御には空の文字列を指定します。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
  --control "1.3.6.1.4.1.26027.1.5.4:false:;" -b "cn=changelog" \
  "(objectclass=*)" "*" +

レスポンス1

サーバーが各変更をSearchResultEntryに格納してクライアントへ送信します。cookie属性では新しいCookieの値を指定します。この値は、外部変更ログのCookie制御にも、エントリとともに送信されます。

# Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4): 
  dc=europe,dc=com:0000012187eae081456200000001;o=example:;
dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog
objectClass: top
objectClass: changeLogEntry
replicationCSN: 0000012187eae081456200000001
replicaIdentifier: 17762
targetDN: cn=chek-piao chea,ou=unit1,o=people,dc=europe,dc=com
changeTime: 20090528155105Z
changes:: cmVwbGFjZTogc2VlQWxzbwpzZWVBbHNvOiBjbj1tY29uZmlnCi0KcmVwbGFjZTogbW9kaW
  ZpZXJzTmFtZQptb2RpZmllcnNOYW1lOiBjbj1EaXJlY3RvcnkgTWFuYWdlcixjbj1Sb290IEROcyxjb
  j1jb25maWcKLQpyZXBsYWNlOiBtb2RpZnlUaW1lc3RhbXAKbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDUy
  ODE1NTEwNVoKLQo=
changeType: modify
changeLogCookie: dc=europe,dc=com:0000012187eae081456200000001;
targetEntryUUID: 08d1830c-02f1-34a6-9cf4-8d1270ec1db0
changeNumber: 0

リクエスト2

最後に返されたエントリから外部変更ログを読み取るために、クライアントがcn=changelogに対する検索リクエストを送信します。今度は、外部変更ログのCookie制御で受信した最後のCookieの値を指定します。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file
  --control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe,dc=com:0000012187eae081456200000001;"
  -b "cn=changelog" "(objectclass=*)"

ノート:

外部変更ログのコンテンツはBase64でエンコードされています。コンテンツのデコードの詳細は、「base64」を参照してください。

32.7.4 外部変更ログ・エントリの形式

外部変更ログで返されるエントリのDN形式を確認できます。

replicationcsn=replicationCSN,replication-domain-DN,cn=changelog

たとえば:

dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog

外部変更ログ・エントリについて次の属性が返されます:

targetDN / MUST
changeType / MUST
changeTime / MUST
changeNumber / MUST // used only for compatibility mode

changes / MAY, MUST for add, mod
newRDN / MAY, MUST for modrdn
deleteOldRDN / MAY, MUST for modrdn
newSuperior / MAY, MUST for modrdn

replicaIdentifier / MAY, OPERATIONAL / specific OUD value
replicationCSN / MAY, OPERATIONAL / specific OUD value
targetEntryuuid / MAY, OPERATIONAL / specific OUD value
changelogcookie / MAY, OPERATIONAL

32.7.5 外部変更ログに含める属性の指定

デフォルトでは、外部変更ログに含まれる属性は、変更操作の影響を受ける属性のみです。したがって、たとえば、エントリのsn属性が変更される場合、その属性のみが外部変更ログに記述されます。ただし、変更操作の影響を受けるかどうかに関係なく、外部変更ログに含める属性のリストを指定できます。また、この属性リストをすべての種類の操作に対して含めるか、削除操作に対してのみ含めるかも指定できます。

ecl-includeプロパティまたはecl-include-del-onlyプロパティを使用して、属性を構成できます。これらのプロパティを使用して属性を構成する手順は、次の項を参照してください。

32.7.5.1 `ecl-include`プロパティを使用した属性の構成

ecl-includeプロパティを使用すると、エントリが変更された場合に外部変更ログに含める属性を構成できます。

ecl-includeプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、エントリが変更された場合に常にcn属性とsn属性を外部変更ログに含めるように指定するには、次のコマンドを実行します:

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \ 
--domain-name dc=example,dc=com \
--add ecl-include:cn --add ecl-include:sn

サーバーが返す外部変更ログ・エントリでは、属性名にtargetという接頭辞が付いています。たとえば、前述の例でいえば、dc=example,dc=comでの変更に対する外部変更ログ・エントリには、targetcn属性とtargetsn属性が必ず含まれています。これらの属性の値は、エントリの変更または移動前のcn属性とsn属性の値です。

32.7.5.2 `ecl-include-del-only`プロパティを使用した属性の構成

ecl-includeプロパティと一緒にecl-include-del-onlyプロパティを使用すると、削除操作についてのみ追加の属性を取得できます。

ecl-include-del-onlyプロパティの値を設定するには、dsconfigコマンドを使用します。

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \ 
--domain-name dc=example,dc=com \
--add ecl-include:cn --add ecl-include:sn --set ecl-include-del-only:true

32.7.6 外部変更ログから除外する属性の指定

外部変更ログを使用するクライアント・アプリケーションは必ずしも、サーバーで実行されたすべてのLDAP操作に関心があるわけではありません。このため、無関連の情報の処理を避けるために、属性のリストをフィルタリングできます。

ecl-blacklistプロパティを使用すると、外部変更ログから除外する属性を構成できます。すべての変更がブラックリスト対象属性に該当する場合のみ、クライアント・アプリケーションへ送信される変更操作がスキップされます。

ノート:

ブラックリスト・メカニズムを使用するには、Cookieモードを使用する必要があります。blacklistプロパティを構成すると、Cookieモードなしではcn=changelogにアクセスできなくなります。

ecl-blacklistプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、email属性とtelephonenumber属性に関連する変更操作を外部変更ログから除外するように指定するには、次のコマンドを実行します:

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com --add ecl-blacklist:email \
--add ecl-blacklist:telephonenumber

32.7.7 外部変更ログを使用するクライアント・アプリケーションの初期化

クライアント・アプリケーションでは、外部変更ログを使用するための特定のサーバー構成は必要ありません。ただし、外部変更ログを使用する必要があるクライアント・アプリケーションを初期化する必要があります。

ノート:

外部変更ログを使用するクライアント・アプリケーションを初期化および再初期化する際は、lastExternalChangelogCookie属性を使用します。lastExternalChangelogCookie属性には、変更ログからの変更を検索するために必要な情報を含むCookieが含まれます。Oracle Unified Directoryでは、遅延しているサーバーについてトポロジ内の外部変更ログの変更の時系列順が統合されます。ただし、例外的なシナリオでは、外部変更ログの変更が適切な時系列順で伝播されない場合があることに注意する必要があります。

32.7.7.1 外部変更ログを使用するクライアント・アプリケーションの初期化

次の例で、ホスト2をホスト1から初期化するシナリオを示します。ホスト1は初期化操作中も固定されず、変更を受信し続けます。次の手順により、ホスト1で受信された変更がホスト2に漏れなく反映されることが保証されます。

ホスト1にある最後の外部変更ログCookieの値を読み取って、ホスト1の最新の状態を保存します。
これは、ルートDSEのlastExternalChangelogCookie属性の値です。たとえば:
```
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
  -s base -b "" "objectclass=*" lastExternalChangelogCookie
  dn:
  objectClass: top
  objectClass: ds-root-dse
  lastExternalChangelogCookie: dc=europe:00000121cea5221c04b100000005 \
    00000121cea5319e04b400000009;
```
ホスト1は固定されず、変更を受信し続けることに注意してください。
ホスト2を初期化するために、Oracle Unified Directoryデータベースをホスト1からエクスポートしてホスト2にインポートします。
エクスポートしたデータベースを使用してアプリケーションを初期化します。
ステップ1で保存した最新の状態を使用して、ホスト2でのレプリケーションを再開します。これで、アプリケーションは最後のCookie値を検索制御の値として提供して、外部変更ログの読取りを開始できます。たとえば:
```
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file
  --control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe:00000121cea5221c04b100000005 \
    00000121cea5319e04b400000009" -b "cn=changelog" "(objectclass=*)"
```

32.7.7.2 ドメイン追加時のクライアント・アプリケーションの再初期化

新しいレプリケーション・ドメインをトポロジに追加すると、そのドメインで外部変更ログがデフォルトで有効になります。外部変更ログを使用するクライアント・アプリケーションを、その新規ドメインに対して再初期化する必要があります。

サーバーでは、提供されたCookieが新規ドメインを参照していなければ検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、欠けているドメインのリストと部分的初期化用のCookie値を含む詳細メッセージを提供します。

次のいずれかの方法でクライアント・アプリケーションを再初期化する必要があります:

完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
1. lastExternalChangelogCookie属性の値を読み取ります。この値は、新規ドメインを含む、トポロジ内の全ドメインを参照しています。
2. 新規ドメインを含む全ドメインを対象にデータベースをエクスポートします。
3. エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
4. これで、アプリケーションはlast_cookie_from_dse_rootを使用して外部変更ログを検索できるようになりました。
部分的再初期化。アプリケーションを新規ドメインに対してのみ再初期化します。
1. 新規ドメインのみを対象にデータベースをエクスポートします。
2. エクスポートの出力を使用してアプリケーションを初期化します。エクスポートの出力には、新規ドメイン内のエントリのみが格納されています。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
3. これで、アプリケーションは、「実行要求を拒否」エラーでサーバーから返された部分的初期化用のCookie値を使用して、外部変更ログを検索できるようになりました。
  
  ノート:
  
  その結果として、すでに処理が完了している一部の更新がリプレイされることがありますが、これはCookie値がデータベースの初期状態を示しているためです。

ノート:

ドラフト互換モードのドラフトAPIでは、アプリケーションが適切に初期化されるようにサーバーが強制することはできません。したがって、ドラフト互換モードでは、新規ドメインが追加されると同時に、そのサーバーにおける変更が外部変更ログに公開されます。

サーバーが新規ドメインに関する変更を公開しないようにするには、「特定のドメインに対する外部変更ログの無効化」を参照してください。特定のドメインに対する変更のみがアプリケーションに通知されるようにするには、そのドメインをベースDNで指定するか(Cookieモードの場合のみ)、targetDN属性の検索フィルタとして指定します。

32.7.7.3 ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化

レプリケーション・ドメインをトポロジから削除したら(または、外部変更ログを特定のドメインに対して無効にしたら)、以後そのドメインでは変更が発生しないことをクライアント・アプリケーションに通知する必要があります。

サーバーでは、提供されたCookieが、削除されたドメインを参照していれば検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、Cookieにあるドメインで削除されたもの(または外部変更ログが無効化されたもの)のリストと継続用のCookie値を含む詳細メッセージを提供します。

クライアント・アプリケーションでは、削除されたドメインを次のいずれかの方法で処理できます:

円滑な継続。この場合、アプリケーションはドメインの削除時の処理に関する独自のポリシーを適用できます。このポリシーの作成を支援するために、アプリケーションでは、サーバーからエラー・メッセージで返された継続用のCookie値を提供して外部変更ログを検索できます。
完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
1. lastExternalChangelogCookie属性の値を読み取ります。この値は、削除されたドメインを除く、トポロジ内の全ドメインを参照しています。
2. 全ドメインを対象にデータベースをエクスポートします。
3. エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
4. これで、アプリケーションはlastExternalChangelogCookieを使用して外部変更ログを検索できるようになりました。

32.7.8 外部変更ログへのアクセスの制御

ECLへのアクセスはグローバルACIで規定されます。これはサーバーで構成できます。デフォルトでは、rootユーザーのみが外部変更ログにアクセスできます。

グローバルACIの構成の詳細は、「dsconfigを使用したグローバルACIの管理」を参照してください。

32.7.9 外部変更ログのパージ

外部変更ログは、レプリケーション変更ログとともにパージされます。

レプリケーション変更ログのパージ間隔の変更の詳細は、「レプリケーション・パージ遅延の構成」を参照してください。

アプリケーションがサーバーに保存されている最も古い変更よりも古いCookie値を指定して、外部変更ログに対する検索リクエストを送信する場合があります。これは、そのアプリケーションからの前回のリクエスト以降にパージが実行されたためです。この場合、サーバーはリクエストを却下し、Cookieが古いことと完全な再同期が必要であることを示します。

32.7.10 サーバーでの外部変更ログの無効化

dsreplication disable-changelogコマンドを使用し、特定のベースDNについてサーバー上の外部変更ログを無効化します。

$ dsreplication disable-changelog -h localhost -p 4444 -D "cn=directory manager" \
  -j pwd-file -b dc=example,dc=com -X -n

32.7.11 特定のドメインに対する外部変更ログの無効化

特定のドメインにおける変更を外部変更ログから除外する必要がある場合があります。特定のレプリケーション・ドメインについて外部変更ログを無効にできます。無効にすると、そのドメインに対する変更が外部変更ログに公開されなくなります。

ドメイン名を取得します。詳細は、「レプリケーション・ドメイン名の取得」を参照してください。
そのドメインの外部変更ログ・ドメイン・プロパティを設定します。
たとえば、スキーマの変更を外部変更ログに公開しないようにするには、次のようにdsconfigコマンドを実行します:
```
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
  set-external-changelog-domain-prop \
  --provider-name "Multimaster Synchronization" --domain-name cn=schema \
  --set enabled:false
```

32.7.12 最後の変更番号の取得

ldapsearchコマンドを使用して、サーバー上の最後の変更番号属性を取得します。

ノート:

「外部変更ログの有効化」の説明に従って、外部変更ログが有効になっているかどうかを確認します。

次のコマンドを実行します。

./ldapsearch -h <hostname> -p <portnumber> -D "cn=Directory Manager" 
-w <password> -s base -b "" objectclass=* lastchangenumber

例

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -w <password>
  -s base -b "" "objectclass=*" lastchangenumber

32.7.13 他の変更ログに依存するアプリケーションの移植

外部変更ログは、LDAP変更ログ・ドラフトに基づいていますが、この変更ログを厳密にはサポートしていません。LDAP変更ログ・ドラフトでは、変更ログを閲覧するためのキーとして整数を使用するのに対し、外部変更ログではCookieを使用します。

LDAP変更ログ・ドラフトの詳細は、http://tools.ietf.org/html/draft-good-ldap-changelog-04を参照してください。

クライアント側では、Cookieメカニズムには次の利点があります:

外部変更ログ・インスタンス間のフェイルオーバーが可能。
複数の外部変更ログ・インスタンス間での負荷分散リクエストが可能。

サーバー側では、Cookieメカニズムには次の利点があります:

マルチマスター環境における実装が容易になる
サーバーで必要とされるリソースが少なくなる
変更を生成する他のアプリケーションに対するパフォーマンスの影響が小さくなる

ノート:

Oracle Directory Server Enterprise Edition (ODSEE)のレトロ変更ログ(RCL)はLDAP変更ログ・ドラフトをサポートしており、固有の追加がいくつかあります。

この節では、以下のトピックについて説明します。

32.7.13.1 外部変更ログとLDAP変更ログ・ドラフトの相違点の理解

次のトピックでは、2つの変更ログの相違点について説明します。これは、クライアント・アプリケーションを移植するときに役立ちます。

32.7.13.1.1 索引の相違点について

LDAP変更ログ・ドラフトでは、変更ログ索引を整数として指定します(changenumber属性)。この形式は、変更ログ・サービスが単一のサーバーによって提供される場合には効果的です(LDAP変更ログ・ドラフトの仕様が策定された時点ではそうでした)。しかし、変更ログ・サービスが複数のサーバーをサポートする場合や、サーバー間のフェイルオーバーをサポートする場合、この整数の形式は不適切です。

ノート:

Oracle Directory Server Enterprise Editionとの互換性を確保するには、cn=changelogでreplicationCSN属性に索引を作成する必要があります。cn=changelog以外のパラメータでreplicationCSN属性に索引を作成すると、パフォーマンスに影響するおそれがあります。

32.7.13.1.2 DITおよびスキーマの相違点について

LDAP変更ログ・ドラフトでは、変更ログ内のエントリに対するDNをchangenumber=changenumber,cn=changelogとして指定します。外部変更ログでは、変更ログ内のエントリに次のDNを使用します:

replicationcsn=replicationCSN,replication-domain-DN,cn=changelog

外部変更ログのスキーマはLDAP変更ログ・ドラフトのスキーマに基づいていますが、Oracle Unified Directoryでは外部変更ログ内の索引をchangenumber属性ではなく、アプリケーションには理解不能なCookieによって管理します。

次の表で、スキーマの相違点について説明します。

元必須任意

元	必須	任意
LDAP変更ログ・ドラフト	`changenumber` `targetDn` `changetype`	`changes` `newRDN` `deleteOldRDN` `newSuperior`
ODSEEレトロ変更ログ	`changenumber` `targetDn` `changetype` `changetime`	`changes` `newRDN` `deleteOldRDN` `newSuperior` `changeHasReplFixupOp` `changeIsReplFixupOp` `deletedEntryAttrs` `replicaIdentifier` (操作属性) `replicationCSN` (操作属性) `targetUniqueId` (操作属性)
Oracle Unified Directory外部変更ログ	`changenumber` `targetDn` `changetype` `changetime`	`changes` `newRDN` `deleteOldRDN` `newSuperior` `replicaIdentifier` (操作属性) `replicationCSN` (操作属性) `targetentryuuid` (操作属性) `changelogcookie` (操作属性)

LDAP変更ログ・ドラフト

changenumber

targetDn

changetype

changes

newRDN

deleteOldRDN

newSuperior

ODSEEレトロ変更ログ

changenumber

targetDn

changetype

changetime

changes

newRDN

deleteOldRDN

newSuperior

changeHasReplFixupOp

changeIsReplFixupOp

deletedEntryAttrs

replicaIdentifier (操作属性)

replicationCSN (操作属性)

targetUniqueId (操作属性)

Oracle Unified Directory外部変更ログ

changenumber

targetDn

changetype

changetime

changes

newRDN

deleteOldRDN

newSuperior

replicaIdentifier (操作属性)

replicationCSN (操作属性)

targetentryuuid (操作属性)

changelogcookie (操作属性)

32.7.13.2 外部変更ログとOracle Directory Server Enterprise Editionレトロ変更ログとの相違点の理解

スキーマおよび実装ベースの値

Oracle Directory Server Enterprise Editionのレトロ変更ログは、ターゲット・エントリの一意IDをtargetuniqueid属性に格納する仕様になっています。この属性値フォーマットは、Oracle Directory Server Enterprise Editionに固有のものです。replicationcsn属性もOracle Directory Server Enterprise Editionに固有の値を保持します。

最初と最後の外部変更ログ索引

Oracle Directory Server Enterprise Editionのレトロ変更ログは、ルートDSEエントリの次の属性をサポートしています。

firstchangenumber属性: 最初の(最も古い)変更ログ索引を整数の変更番号として保持します。

この値は、変更ログがパージされると更新されます。アプリケーションは変更ログ・サーバーに接続する前に、最初の変更ログ索引を読み取り、それをアプリケーションが格納した変更ログ索引と比較します。アプリケーションが格納した最後の変更ログ索引よりも最初の変更ログ索引の方が新しければ、アプリケーションの索引から最初の変更ログ索引までの変更がサーバーから返されないことをアプリケーションは認識します。この変更は、すべてのエントリを読み取ることによってのみ取得できます(完全再同期)。

Oracle Unified Directoryの外部変更ログでは、この手続きをアプリケーションが行う必要がありません。かわりに、Oracle Unified Directoryサーバーが確認を行い、Cookieが古すぎる場合はリクエストを却下します。詳細は、「外部変更ログの使用」を参照してください。
lastchangenumber属性: 最後の(最も新しい)変更ログ索引を整数の変更番号として保持します。

Oracle Unified Directoryの外部変更ログは、lastExternalChangelogCookie属性に相当する機能をサポートしています。lastExternalChangelogCookie属性には、変更ログからの変更を検索するために必要な情報を含むCookieが含まれます。詳細は、「外部変更ログの使用」を参照してください。

パージの遅延

Oracle Directory Server Enterprise Editionのレトロ変更ログでは、外部変更ログと通常のレプリケーション変更ログが別々のデータベースになっています。Oracle Unified Directoryでは、この2つの変更ログが同じデータベースに格納されています。この設計上の決定には、それぞれの利点があります。この設計上の決定の付加的な結果として、Oracle Directory Server Enterprise Editionでは2つの別々のトリミング・ポリシー(パージの遅延)を設定できるのに対し、Oracle Unified Directoryのトリミング・ポリシーは同一です。

32.7.13.3 LDAP変更ログ・ドラフトおよびOracle Directory Server Enterprise Editionレトロ変更ログとの互換性のためのAPIについて

Oracle Unified Directoryは、LDAP変更ログ・ドラフトと互換性のある追加APIを備えており、Oracle Directory Server Enterprise Editionのレトロ変更ログの追加機能の大部分をサポートしています。このAPIの使用は、サーバー側のCPUとデータベース(ディスク)領域の面、および外部変更ログ・サーバー間でフェイルオーバーするアプリケーションの計算処理面のパフォーマンスに影響します。

サーバーが外部変更ログに対するリクエストを変更ログCookieなしで受信すると、この互換性API (互換性モード)の使用が構成されます。サーバーは、エントリとともにchangenumber属性を返します。その値は1ずつ増加していく整数です。

クライアントは、changenumberに対するフィルタを指定することで外部変更ログを検索できます。ターゲット・エントリの一意IDは、Oracle Directory Server Enterprise Editionのレトロ変更ログと互換性のある形式でtargetuniqueidという属性に格納されます。最初と最後のchangenumberは、ルートDSEエントリの属性として存在します。

互換性APIの制限事項

Oracle Unified Directoryでは、外部変更ログを専用のデータベースに格納しないため、特定の索引など、JEBバックエンドでサポートされている機能の一部をサポートしていません。

また、LDAP変更ログ・ドラフトで指定されたchangenumberベースの順序をサポートするために、Oracle Unified Directoryではchangenumberからレプリケーション状態へのマッピングを格納する必要があります。サーバーはリクエストの処理時に、リクエスト・フィルタで提供されたchangenumberからレプリケーション・ステータスの取得を試みます。取得できない場合は、リクエストが却下されます。

32.8 Oracle Unified Directoryでのツームストンの管理

Oracle Unified Directoryでは、1つのレプリカで削除されたディレクトリ・エントリを、レプリケーションで不要になるまで維持するために、ツームストン機能がサポートされています。

この項では、次の項目について説明します。

32.8.1 ツームストン・サポートについて

エントリがLDAP削除操作のターゲットである場合、通常、Oracle Unified Directoryにより、このエントリはディレクトリ・データベースから削除されます。ただし、ツームストン作成が有効化されている場合、この削除操作は論理削除となり、このエントリがディレクトリによってデータベースから物理的に削除されることはありません。かわりに、ディレクトリでは、このエントリを特定のオブジェクト・クラスのツームストン・エントリに変換します。ツームストン・エントリでは、そのnsUniqueIDがRDNとして使用されます。

ツームストンにより、管理者は、誤って削除された1つ以上のエントリを必要に応じて元のエントリに復元できます。

ツームストン・サポートは、Oracle Unified Directoryレプリケーションで一部の削除競合を解決する場合に役立ちます。レプリケーション中、ディレクトリ・サーバーとレプリケーション・サーバー間の接続に失敗したことが原因で、サーバーがクラッシュする場合があります。クラッシュ後、一部の操作はディレクトリ・サーバーのデータベースでコミットされたものの、レプリケーション・サーバーに送信されていない可能性があります。このような場合、レプリケーション・サーバーでは、ツームストン・エントリを内部的に使用して競合を解決します。

ノート:

ツームストンを含むレプリカ(Aとします)がパージ間隔を超えてオフラインとなった場合、問題が発生する可能性があります。このレプリケーションがレプリケーション・リングに接続されていると、その他のサーバーとの競合が発生する可能性があり、この場合、これらのツームストン・エントリはパージされることがあります。レプリケーション・トポロジから選択したマスターで、Aを初期化するのが最適です。

32.8.2 ツームストン・エントリについて

ツームストンは読取り専用エントリであり、異なるDNで格納されます。ただし、クライアントの観点からは、ツームストンのDNは削除されたエントリと同じままとなります。

ツームストン・エントリには、tombstoneまたはnstombstoneのいずれかの、特別なオブジェクト・クラス値が含まれています。ツームストン・エントリには、元の削除されたエントリのすべての属性またはそれらの一部のみを含めることができます。

 	dn: cn=u2,cn=users,dc=example,dc=com 
    objectClass: person 
    objectClass: inetOrgPerson 
    objectClass: organizationalPerson 
    objectClass: orclIDXPerson 
    objectClass: nstombstone 
    objectClass: top 
    objectClass: tombstone 
    objectClass: person 
    objectClass: organizationalPerson 
    objectClass: inetOrgPerson 
    objectClass: orclIDXPerson 
    objectClass: top 
    objectClass: tombstone 
    objectClass: nstombstone 
    givenName: useri 
    description: bidule 
    cn: usersSuffix 
    cn: u2 
    sn: u2 
    userPassword: {SSHA}zL22oCGjlG80cmbvh9jnzXAIyUfDSO+y4gRi+w== 
    l: London 
    orclGUID: 859b759ea60746a0bb271e4a46007f24 
    pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config 
    deleteTimestamp: 20110922084753Z 
    subschemaSubentry: cn=schema 
    proximity: -1 
    createTimestamp: 20110922084752Z 
    pwdChangedTime: 20110922084752.126Z 
    structuralObjectClass: orclIDXPerson 
    entryDN: cn=u2,cn=users,dc=example,dc=com 
    entryUUID: 859b759e-a607-46a0-bb27-1e4a46007f24 
    creatorsName: cn=Internal Client,cn=Root DNs,cn=config 
    modifyTimestamp: 20110922084753Z 
    nscpEntryDN: cn=u2,cn=users,dc=example,dc=com 
    modifiersName: cn=Internal Client,cn=Root DNs,cn=config 
     1316681273304

32.8.3 ツームストン・サポートの有効化または無効化

Oracle Unified Directoryでは、ツームストン・サポートはデフォルトで有効化されています。DBローカル・バックエンド・ワークフロー要素のtombstone-creation-enabled拡張プロパティを使用して、ツームストンを無効化または有効化できます。

userRootバックエンドに対してツームストンを無効化するには:

dsconfig set-workflow-element-prop \ 
          --element-name userRoot \ 
          --set tombstone-creation-enabled:false \ 
          --hostname localhost \ 
          --port 1444 \ 
          --trustAll \ 
          --bindDN cn=directory\ manager \ 
          --bindPasswordFile /local/tests/password \ 
          --no-prompt

tombstone-creation-enabled拡張プロパティのパラメータの説明は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。

32.8.4 ツームストン・エントリの検索

ツームストン・エントリは、検索リクエストの検索フィルタにobjectclass=tombstoneまたはobjectclass=nstombstoneを追加しないかぎり、通常の検索操作では表示されません。

次のldapsearchコマンドでは、dc=example,dc=comの下にツームストン・エントリが返されます。

$ ldapsearch -h localhost -p 5444 -D "cn=Directory Manager" -j pwd-file.txt -b dc=example,dc=com "(objectclass=nsTombstone)"
dn: uid=user.3,ou=people,dc=com
postalAddress: Aaron Atrc$59748 Willow Street$Green Bay, TN 66239
postalCode: 66239
description: This is the description for Aaron Atrc.
uid: user.3
userPassword: {SSHA512}li0gmRHdPtL326Pc2B2tIfGe/RdITcQXzZshsR96nKl25FaTYFXvp9nq1
rNzafjKKFkgRrhGEwDggn6KaMsjym0Ggzm36oAh
employeeNumber: 3
initials: AKA
givenName: Aaron
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: nstombstone
objectClass: top
objectClass: tombstone
pager: +1 197 025 3730
mobile: +1 890 430 9077
cn: Aaron Atrc
telephoneNumber: +1 094 100 7524
sn: Atrc
street: 59748 Willow Street
homePhone: +1 332 432 4295
mail: user.3@maildomain.net
l: Green Bay
st: TN
orclGUID: 8264e7f807f438879b9833ca1d0ed04a
pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config
deleteTimestamp: 20150227113328Z
subschemaSubentry: cn=schema
changelog: cn=changelog
structuralObjectClass: inetOrgPerson
dssynchist:
dn:0000014bcad0132714a000000003:del
nsUniqueId: 8264e7f807f438879b9833ca1d0ed04a
entryDN: uid=user.3,ou=people,dc=com
entryuuid: 8264e7f807f438879b9833ca1d0ed04a
nscpEntryDN: uid=user.3,ou=people,dc=com
modifyTimestamp: 20150227113328Z
modifiersName: cn=directory manager

32.8.5 ツームストン・エントリの自動パージ

ツームストン・エントリはリソース(索引、データベース記憶域)を消費するため、無期限には保管されません。パージ・スレッドは、構成パラメータtombstone-purge-intervalにより、特定の間隔で定期的に起動されます。

ツームストン・パージ・スレッドにより、tombstone-lifetime構成パラメータで指定された時間より古いツームストン・エントリは削除されます。ツームストン・エントリには、デフォルトで1週間の保存期間が設定されています。この遅延後、サーバーにより、これらのエントリは自動的に消去されます。

ノート:

tombstone-lifetimeパラメータの時間間隔が短すぎないようにしてください。ツームストン保存期間の間隔が短いと、パージ対象のツームストンが多数存在する場合、サーバーが応答できない可能性があります。

ツームストン保存期間を特定の間隔に変更するには:

dsconfig set-workflow-element-prop \ 
          --element-name userRoot \ 
          --set tombstone-lifetime:1440\ m \ 
          --hostname localhost \ 
          --port 1444 \ 
          --trustAll \ 
          --bindDN cn=directory\ manager \ 
          --bindPasswordFile /local/tests/password \ 
          --no-prompt

ツームストンのパージ間隔を変更するには:

dsconfig set-workflow-element-prop \ 
          --element-name userRoot \ 
          --set tombstone-purge-interval:6\ m \
          --hostname localhost \ 
          --port 1444 \ 
          --trustAll \ 
          --bindDN cn=directory\ manager \ 
          --bindPasswordFile /local/tests/password \ 
          --no-prompt

tombstone-lifetimeおよびtombstone-purge-intervalプロパティのパラメータの説明は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する説明を参照してください。

32.8.6 ツームストン・エントリの削除

自動パージを待機せずに、ツームストン・エントリを削除することもできます。

ツームストン・エントリを削除するには:

次の検索フィルタを使用してエクスポートからツームストン・エントリを除外し、1つのサーバーからデータ・セットをエクスポートします。
```
/export-ldif -n userRoot -l /tmp/export_no_tombstones.ldif –excludeFilter "objectclass=tombstone"
```
このフィルタにより、objectclass=tombstoneを含むすべてのエントリがLDIFファイルから除外されます。
export-ldifを実行したサーバーを含めて、ファイルをインポートする必要があるディレクトリ・サーバーを停止します。

LDIFファイルをインポートします。

/import-ldif -n userRoot -l /tmp/export_no_tombstones.ldif

サーバーを再起動します。

トポロジ内のあらゆるディレクトリ・サーバー対してこれらのステップを実行し、ツームストン・エントリを削除できます。dsreplication statusコマンドでは、バックエンドのエントリ数の違いは表示されません。

32.9 スキーマのレプリケーションの構成

スキーマのレプリケーションはデフォルトで有効になっています。サーバー設定の一部としてレプリケーションを構成すると、トポロジ内の既存のサーバーのスキーマを使用して、新しいサーバーのスキーマが自動的に初期化されます。

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

32.9.1 スキーマ・ソースの指定

dsreplication enableコマンドでレプリケーションを構成するとき、2番目のディレクトリ・サーバーを使用して1番目のサーバーのスキーマを初期化するように指定できます。オプションを指定しないと、1番目のディレクトリ・サーバーのスキーマがデフォルトで使用されます。

次の例では、host1のデータを使用してhost2を初期化し、host2のスキーマを使用してhost1のスキーマを初期化します:

$ dsreplication enable --host1 host1 --port1 4444 \
  --bindDN1 "cn=Directory Manager" --bindPasswordFile1 pwd.txt \
  --replicationPort1 8989 --host2 host2 --port2 4444 \
  --bindDN2 "cn=Directory Manager" --bindPasswordFile2 pwd.txt \
  --replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \
  --baseDN "dc=example,dc=com" --useSecondServerAsSchemaSource -X

32.9.2 スキーマのレプリケーションの無効化

環境によっては、スキーマをレプリケートしたくない場合もあります。スキーマは、"cn=schema"という別個のベースDNの下にレプリケートされます。

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

32.9.2.1 スキーマをレプリケートしないようにする指定

dsreplication enableコマンドでレプリケーションを構成するとき、スキーマをレプリケートしないように指定するには、--noSchemaReplicationオプションを使用します。

ノート:

QuickSetupを使用してレプリケーションを有効にする場合は、スキーマをレプリケートしないようには指定できません。

32.9.2.2 スキーマのレプリケーションの無効化

現在スキーマがレプリケートされている既存のトポロジでこの機能を無効にするには、スキーマ・ベースDNのレプリケーションを無効にします。次の例では、ローカル・ホストのポート1389で稼働しているディレクトリ・サーバーのスキーマのレプリケーションを無効にします:

$ dsreplication disable -h localhost -p 1389 -D "cn=directory manager" \
  -j pwd-file -b "cn=schema" -X

ノート:

この例は、トポロジ全体のスキーマのレプリケーションを無効にするものではありません。トポロジ全体のスキーマのレプリケーションを無効にするには、トポロジ内の各ディレクトリ・サーバーで同等のコマンドを実行する必要があります。

32.10 読取り専用サーバーへのレプリケーション

Oracle Unified Directoryのレプリケーション・モデルはマルチマスター・モデルです。つまり、トポロジ内のすべてのレプリケーション・サーバーが読取り操作と書込み操作の両方を処理できます。ただし、特定のディレクトリ・サーバーを読取り専用に設定できます。そのサーバーでは、LDAPクライアントからの追加操作、変更操作および削除操作が却下されます。

ノート:

読取り専用ディレクトリ・サーバーは、Oracle Directory Server Enterprise Editionのレプリケーション・モデルにおけるコンシューマ・レプリカと同様に機能します。

この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2のディレクトリ・サーバーを読取り専用レプリカとして構成します。この例では、dsconfigコマンドを使用します。このコマンドは、管理コネクタを介してサーバー構成にアクセスします。「サーバーへの管理トラフィックの管理」を参照してください。

dsconfigコマンドを使用してhost2のwritability-modeを設定します。

$ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
  set-global-configuration-prop --set writability-mode:internal-only

internal-onlyという書込み可能性モードは、サーバーでレプリケーション操作は処理されるが、LDAPクライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。

32.11 レプリケーションの非一貫性の検出および解決

ディレクトリ・サーバーのレプリケーションは、ハードウェアの故障やディレクトリ・サーバーの再起動、ネットワーク障害が発生しても、レプリケートされたデータベース間で一貫性が維持されるように設計されています。しかし、それでも、ハードウェアの故障(ディスク・エラー、メモリー・エラー)やソフトウェアの不具合(これに起因するメモリーの破損)によってデータベース間に不整合が発生する可能性があります。

次のトピックでは、レプリケーションの非一貫性を検出する方法と、非一貫性が確認された場合にそれを解決する方法について説明します。

32.11.1 レプリケーションの非一貫性の種類について

非一貫性が発生しても、しばらくそれが顕在化しない場合もあれば、レプリケーション・エラーやアプリケーション・エラーが引き起こされる場合もあります。

非一貫性の例を次に示します:

あるエントリがレプリケーション・トポロジ内の1つのディレクトリ・サーバーを除くすべてのディレクトリ・サーバーに存在します。
あるエントリのDNが1つのディレクトリ・サーバーでのみ、他のディレクトリ・サーバーと異なります。
あるエントリの属性が1つのディレクトリ・サーバーでのみ、レプリケーション・トポロジ内の他のディレクトリ・サーバーと異なります。

32.11.2 非一貫性の検出

レプリケーション・ログ・ファイルおよびユーザーから報告されたエラーをチェックして、レプリケーション中に非一貫性を検出できます。

レプリケーション・ログ・ファイル内の情報を確認する。レプリケーション・ログ・ファイルはデフォルトで構成されており、レプリケーション・メカニズムによって検出された非一貫性が記録されます。たとえば、トポロジ内の1つのディレクトリ・サーバーに存在しないエントリに対して変更操作が実行されたとします。レプリケーションがこの操作をこのサーバーに対してリプレイしようとすると、問題が検出され、logs/replicationエラー・ログにエラーが書き込まれます。この種のエラーによってレプリケーションが停止することはありませんが、操作がリプレイされないため、管理者は非一貫性を修正する必要があります。
クライアント・アプリケーションまたはユーザーから報告されるエラーに注意する。クライアント・アプリケーションやユーザーがディレクトリ・サーバーへのアクセス時に、レプリケーションの非一貫性に起因する可能性のあるエラーに遭遇する場合があります。
データベースの一貫性を定期的に確認する。現行のリリースのディレクトリ・サーバーでは、これらの確認は検索またはデータベース・エクスポートによって手動で行う必要があります。

32.11.3 非一貫性の解決

トポロジ内の単一のディレクトリ・サーバーでレプリケーションの非一貫性が検出された場合、通常のLDAP操作でこの非一貫性を修正することはできません。LDAP操作自体がトポロジ内の他のディレクトリ・サーバーにレプリケートされ、それらのサーバーを損傷するおそれがあるためです。また、修正には、ディレクトリ・サーバーによって生成された属性(entryuid属性、modifyTimestamp属性など)の変更が伴う場合もあります。通常のLDAP操作ではそのような属性は変更できません。

したがって、レプリケーションの修復操作は、レプリケーション修復制御(OID: 1.3.6.1.4.1.26027.1.5.2)を指定するLDAP操作を使用して行う必要があります。

注意:

レプリケーション修復制御を使用すると、ディレクトリ・サーバーが通常行ういくつかの制御をスキップできます。このため、レプリケーション修復制御は、一貫性の問題が検出されアサートされた場合にのみ、細心の注意を払って使用してください。

修復制御により、操作の通常の処理が次のように変更されます:

entryuuid、ds-sync-histなど通常は変更や追加ができない(NO-USER-MODIFICATION)属性を操作で変更できるようになります。
操作にレプリケーション変更番号が関連付けられません。
操作がレプリケーション・サーバーに公開されず、ローカルのみの操作になります。
レプリケーションが競合の解決を試みないか、この操作の履歴情報を生成しません。
この操作に対しては、ほとんどのスキーマ・チェックが実行されません。

たとえば、次のldapmodify操作は、changes.ldifファイルに格納されている変更を使用して、host1上のエントリのみを修復します:

$ ldapmodify -J 1.3.6.1.4.1.26027.1.5.2 -h localhost -p 1389 \
  -D "cn=Directory Manager" -j pwd-file -f changes.ldif

エントリを修復するときには、その通常属性だけでなく、ディレクトリ・サーバーによって生成されたmodifyTimestamp、modifiersName、createTimestamp、creatorsName、ds-sync-histなどの属性もすべて修復する必要があります。これらの属性の値を、正しい値が格納されているディレクトリ・サーバーから読み取り、不適切な値があるサーバーで再作成してください。

ds-sync-hist属性には、レプリケーションによる変更の競合の解決に使用される履歴情報が保持されています。この属性を参照できるのは管理者のみです。

32.11.4 名前の競合の解決

サーバー同士が互いの変更をレプリケートする前にエントリが作成された場合、同じDNを持つエントリが別々のディレクトリ・サーバーで作成される場合があります。リモート操作がローカル・サーバーにレプリケートされると、名前の競合が発生します。名前の競合の結果として、競合エントリがローカル・サーバーに作成されます。

競合エントリは、entryuuid=entryUid+oldRDNという形式の固有のDNを持ちます。どの競合エントリにもds-sync-conflict属性があり、その値は競合する通常エントリのDNです。

たとえば、cn=bjensen,ou=People,dc=example,dc=comというエントリが2つのディレクトリ・サーバー上で同時に作成されたとします。サーバー1のエントリにはuid1という一意IDが割り当てられ、サーバー2のエントリにはuid2という一意IDが割り当てられます。レプリケーション後、どちらのディレクトリ・サーバーにも次の2つのエントリが存在することになります:

cn=bjensen,dc=example,dc=com
...
entryuuid=uid2+cn=bjensen,dc=example,dc=com
  ds-sync-conflict:cn=bjensen,dc=example,dc=com

競合エントリを特定したら、そのエントリの名前を変更して一意のDNを与えることができます。

競合エントリのネーミング属性が複数値の場合、次のようにして競合エントリの名前を変更できます:

古いRDN値を維持しながら、エントリ名を変更します。たとえば:
```
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: entryuuid=uid2+cn=bjensen,dc=example,dc=com
changetype: modrdn
newrdn: cn=bljensen
deleteoldrdn: 0
^D
```
このステップで古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。

ネーミング属性の古いRDN値と競合マーカー属性を削除します。たとえば:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: cn=bljensen,dc=example,dc=com
changetype: modify 
delete: cn
cn: bjensen
delete: ds-sync-conflict
^D

dc(ドメイン・コンポーネント)など、競合エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、次のように仮の名前をエントリに付与する必要があります:

異なるネーミング属性を使用してエントリ名を変更し、古いRDN値は維持します。たとえば、次のようになります。
```
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: entryuuid=uid2+dc=HR,dc=example,dc=com
changetype: modrdn
newrdn: o=TempHR
deleteoldrdn: 0
^D
```
このステップで古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。

目的のネーミング属性を一意の値に変更して、競合マーカー属性を削除します。たとえば:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: o=TempHR,dc=example,dc=com
changetype: modify 
replace: dc
dc: NewHR
delete: ds-sync-conflict
^D

エントリ名を変更して目的のネーミング属性に戻し、仮のRDNを削除します。たとえば:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: dc=NewHR,dc=example,dc=com
changetype: modrdn 
newrdn: dc=NewHR
deleteoldrdn: 1
^D

32.12 `dsreplication`を使用した証明書の管理

レプリケート対象のOracle Unified Directoryサーバーでは、証明書を使用して認証の実行およびレプリケーション通信の暗号化を行います。

次のdsreplicationサブコマンドを使用して、これらの証明書を管理できます。

ノート:

この項で説明する証明書は、内部のレプリケーション通信プロセスで使用され、LDAPクライアントと通信するためにサーバーで使用される証明書とは異なります。

dsreplicationサブコマンド(構文を含む)の詳細は、「dsreplication」を参照してください。

32.12.1 `dsreplication list-certs`を使用した証明書の一覧表示

list-certsサブコマンドでは、デプロイメントでレプリケート対象サーバーが使用する証明書を表示します。

たとえば、レプリケーション・デプロイメントのすべての証明書を表示する場合

$ dsreplication list-certs -j /tmp/password.txt -X -n
Establishing connections ..... Done.

Reading Certificates ..... Done.

host1.example.com:4444
==============
User DN:   CN=host1.example.com, O=Oracle Unified Directory Certificate
Validity:  From November 7, 2013 1:48:55 PM CET to November 2, 2033 1:48:55 PM CET
Issuer:    CN=host1.example.com, O=Oracle Unified Directory Certificate

host1.example.com:5444
==============
User DN:   CN=host1.example.com, O=Oracle Unified Directory Certificate
Validity:  From November 7, 2013 1:48:55 PM CET to November 2, 2033 1:48:55 PM CET
Issuer:    CN=host1.example.com, O=Oracle Unified Directory Certificate

32.12.2 `dsreplication regenerate-cert`を使用した証明書の再生成

regenerate-certサブコマンドでは、レプリケーション・トポロジ内の指定されたサーバーまたはすべてのサーバーで使用される証明書を再生成します。デフォルトでは、Oracle Unified Directoryサーバーはレプリケーションのためにいくつかの証明書を自動的に生成します。このコマンドを使用すると、必要に応じてこれらの証明書を再生成できます(たとえば、証明書の有効期限が間もなく終了する場合)。

ノート:

独自の証明書を指定した場合(たとえば、dsreplication set-certサブコマンドを使用した場合)は、これらの証明書の削除が試行されるため、このコマンドの使用はお薦めしません。

たとえば、ポート4444を使用するhost1.example.comサーバーの証明書を再生成する場合

$ dsreplication regenerate-cert -h host1.example.com -p 4444 -X -j /tmp/password.txt -n --adminUID admin
Establishing connections ..... Done.

After the generation of the new certificate for server host1.example.com:4444,
the references to the old certificate will be removed.

Regenerating the Certificate of Server host1.example.com:4444 ..... Done.
Propagating certificate public keys ..... Done.
Reestablishing replication connections on server host1.example.com:4444 .... Done.
Checking registration information ..... Done.

レプリケートされるすべてのサーバーの証明書を再生成するには、--allオプションを含めます。

32.12.3 `dsreplication set-cert`を使用した証明書の指定

set-certサブコマンドでは、レプリケーション・システムで使用する必要がある証明書を指定できます。また、他のレプリケート対象サーバーとの通信に使用する公開キーを含むキーストアも指定します。

たとえば、keytoolなどのユーティリティを使用してmy-ads-keystoreという名前の自己署名証明書を生成した後に、次のようにset-certサブコマンドを実行します。

$ dsreplication set-cert -X
 
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server hostname or IP address [host1.example.com]: 
Directory server administration port number [4444]: 
Global Administrator User ID [admin]:
Password for user 'admin':
 
Establishing connections ..... Done.
 
Choose the type of the key store.
    1)  JKS
    2)  JCEKS
    3)  PKCS12
    4)  PKCS11
    5)  Other (File Based)
    6)  Other (Hardware Based)
    q)  quit

Enter choice [1]: 

You must provide the path of the key store containing the certificate to be
used by the replication.  The server must have read access rights to thispath.

Key store path: /users/admin/my-ads-truststore

You must provide the path of the file containing the password (PIN) in clear
of the key store.  The server must have read access rights to this file.

Key store password (PIN) file: /tmp/password.txt

The server allows to encrypt the key store password file '/tmp/password.txt'.
Note that the server must have write access rights on the file to do so.
Do you want to encrypt the key store password file? (yes / no) [no]:
 
Choose the Nickname of the Certificate:
    1)  my-ads-truststore

    q)  quit
Enter choice [my-ads-truststore]: 
Updating the certificate configuration of server host1.example.com:4444 ..... Done.
Propagating certificate public keys ..... Done.
Reestablishing replication connections on server host1.example.com:4444 ........................... Done.
Checking registration information ..... Done.
See /tmp/oud-replication-356794289708010450.log
for a detailed log of this operation.

32.12.4 `dsreplication verify`を使用した証明書の検証と修正

verifyサブコマンドでは、レプリケート対象サーバーの構成を検証し、必要に応じて(対話モードで)レプリケーション・システムで使用される証明書に関連する問題を修正できます。

レプリケーション・システムで使用される証明書を検証して修正するには、verifyサブコマンドを対話モードで実行します。たとえば:

$ dsreplication -X 

What do you want to do?

    1)   Enable Replication
    2)   Disable Replication
    3)   Initialize Replication on one Server
    4)   Initialize All Servers
    5)   Pre External Initialization
    6)   Post External Initialization
    7)   Display Replication Status
    8)   Purge Historical
    9)   Set the Trust Flag of a Directory Server
    10)  Enable External Changelog
    11)  Disable External Changelog
    12)  Verify Server Configuration
    13)  >>>> Replication Certificate Management

    q)   quit

Enter choice: 12

>>>> Specify Oracle Unified Directory LDAP connection parameters

Directory server host name or IP address [host1.example.com]: 

Directory server administration port number [4444]: 

Global Administrator User ID [admin]: 

Password for user 'admin': 

Establishing connections ..... Done.

No errors were found with the configured host names.  The following host names
have been found in the registration information to identify the different
replicated servers:
host1.example.com
host2.example.com
host3.example.com

Do you want to update the host names for the servers? (yes / no) [no]: no

The replication servers are consistently referenced in the configuration.
The replication server values in the configuration are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:9989

What do you want do?

    1)  Provide directly the replication server values to be used
    2)  Do not update the configuration

Enter choice [2]: 

Checking certificates ..... Done.

The following certificates are missing in the trust store of server host1.example.com:4444:
- Certificate of Server host2.example.com:4444

Do you want to repair the issues with the certificates? (yes / no) [yes]: yes
Fixing certificates ..... Done.
Reestablishing replication connections on server host1.example.com:4444 .......... Done.
Reestablishing replication connections on server host2.example.com:4444 .......... Done.
Reestablishing replication connections on server host3.example.com:4444 .......... Done.
Checking registration information ..... Done.

See /tmp/oud-replication-356794289708010450.log
for a detailed log of this operation.

32.13 `verify`サブコマンドの使用

verifyサブコマンドのコンテキストの説明およびdsreplicationとともにverifyサブコマンドを使用する方法の例は、これらのトピックを参照してください。

32.13.1 `verify`サブコマンドについて

verifyサブコマンドでは、レプリケート対象サーバーのレプリケーション構成を検証し、必要に応じて(対話モードで)非一貫性を修正できます。

verifyサブコマンドは対話モードで実行することをお薦めします(つまり、--no-promptオプションは使用しません)。レプリケーション構成に非一貫性が見つかった場合は表示されるため、対話形式で修正できます。

verifyサブコマンドを使用して次の内容を実行します。

到達不能なサーバーへの参照を削除します(たとえば、クラッシュしてリカバリ不能または正常にアンインストールされなかったため)。
レプリケーション・システムで使用される証明書に関連する構成の問題を修正します。
レプリケーション構成で使用されるホスト名を更新します。

32.13.2 `dsreplication verify`を使用したレプリケーション構成の検証と修正

verifyサブコマンドを対話モードで実行して、レプリケーション構成を検証および修正します。

たとえば:

$ dsreplication -X 
What do you want to do?
 
    1)   Enable Replication
    2)   Disable Replication
    3)   Initialize Replication on one Server
    4)   Initialize All Servers
    5)   Pre External Initialization
    6)   Post External Initialization
    7)   Display Replication Status
    8)   Purge Historical
    9)   Set the Trust Flag of a Directory Server
    10)  Enable External Changelog
    11)  Disable External Changelog
    12)  Verify Server Configuration
    13)  >>>> Replication Certificate Management
 
    q)   quit
 
Enter choice: 12
 
 
>>>> Specify Oracle Unified Directory LDAP connection parameters
 
Directory server host name or IP address [host1.example.com]: 
 
Directory server administration port number [4444]: 
 
Global Administrator User ID [admin]: 
 
Password for user 'admin': 
 
Establishing connections ..... Done.
 
No errors were found with the configured host names.  The following host names
have been found in the registration information to identify the different
replicated servers:
host1.example.com
host2.example.com
host3.example.com
 
Do you want to update the host names for the servers? (yes / no) [no]: 
 
The following replication servers do not have the complete list of replication
server values in their configuration:
- host2.example.com:8989
The replication servers must have the complete list of replication server
values.
 
The following replication domains do not have the complete list of replication
server values in their configuration:
- host2.example.com:4444(cn=admin data)
- host2.example.com:4444(cn=schema)
- host2.example.com:4444(dc=example,dc=com)
If they have not been configured this way intentionally, the configuration of
the replication domains should be updated.
 
The replication server values in the configuration are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:8989
 
What do you want do?
 
    1)  Use the interactive assistant
    2)  Provide directly the replication server values to be used
    3)  Do not update the configuration
 
Enter choice [1]: 
 
The replication server values proposed after running the assistant are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:8989
 
What do you want to do?
 
    1)  Use the values above
    2)  Use the values above but do not update the replication domains
    3)  Provide the values again
    4)  Do not update the configuration
 
    q)  quit
 
Enter choice [1]: 
 
Checking certificates ..... Done.
No problems were found with the certificates used by the replication.
 
Updating replication server references ..... Done.
 
See /tmp/oud-replication-6260669521027550543.log
for a detailed log of this operation.

32.14 履歴レプリケーション・データのパージの理解

Oracle Unified Directoryは、レプリケーション操作の結果としてサーバーで行われたすべての変更の履歴を維持します。この履歴レプリケーション・データは各ユーザー・エントリの属性に格納され、いずれ大量のディスク領域を占有する可能性があります。そのため、エントリが変更された時点で履歴情報はパージされます。または、管理者が明示的にコマンドを実行してデータをパージすることもできます。

デフォルトでは、1日以上経過した情報がパージされます。パージ対象とするデータの経過時間を指定するには、レプリケーション・ドメインのconflicts-historical-purge-delayプロパティの値を設定します。次の例では、5日以上経過したデータをパージするように指定します。プロパティ値を表す単位は分です。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
  set-replication-domain-prop --provider-name "Multimaster Synchronization" \
  --domain-name dc=example,dc=com --set conflicts-historical-purge-delay:7200m

また、履歴データを即時にパージしたり、タスクをスケジュールして指定時刻にデータをパージすることもできます。たとえば、あるサーバーを大量のエントリで初期化した後、それらのエントリに相当数の変更を加えたとします。その結果生成されたレプリケーション履歴データにより、データベースのサイズが大幅に増加します。その後、そのサーバーが主に読取り操作に使用された場合、履歴データのパージをトリガーする変更が行われないため、データベースのサイズは大きいままになってしまいます。この場合、1回かぎりのパージ・タスクを実行することで、初期変更によって生成された履歴データを削除し、データベースをより適切なサイズに戻すことができます。

パージ処理にはしばらく時間がかかる場合があるため、パージの最大継続時間を秒単位で指定する必要があります。履歴データを即時にパージするには、次のコマンドを実行します:

$ dsreplication -h localhost -p 4444 --adminUID admin --adminPasswordFile pwd.txt \
  purge-historical --maximumDuration 3600 --baseDN dc=example,dc=com -X -n

スケジューリング・コマンドの詳細は、「タスクとしてのコマンドの構成」を参照してください。

32.15 分離レプリカの理解

分離レプリカとそのデプロイメント・シナリオを理解するには、これらのトピックを参照してください。

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

32.15.1 分離レプリカについて

分離レプリカとは、他のレプリカから変更を受け入れてリプレイできるが、接続先のレプリケーション・サーバーに変更を送信できないディレクトリ・サーバーのことをいいます。分離レプリカは、トポロジに対するデータ更新のソースにはなれません。分離レプリカを使用すると、特定のディレクトリ・サーバーをレプリケーション・トポロジ内の他のサーバーから分離できます。

トポロジ内のすべてのディレクトリ・サーバーにtrusted構成プロパティがあります。このプロパティは、デフォルトではtrueに設定されています。トポロジ内の信頼できないサーバーとして構成すると、つまり、trusted構成プロパティをfalseに設定すると、分離レプリカとして認識されます。信頼できないディレクトリ・サーバーに由来するデータは、レプリケーション・サーバーによって破棄されます。これにより、分離レプリカがレプリケーション・トポロジ内でデータ更新のソースにならないことが保証されます。

信頼できるサーバーか信頼できないサーバーかを構成できるのは、ディレクトリ・サーバーのみです。レプリケーション・サーバーにはtrusted構成フラグがありません。

特定のディレクトリ・サーバーを信頼できないサーバーとして構成するには、次のようにdsreplication set-trustコマンドを使用します:

$ dsreplication --adminUID admin --adminPasswordFile pwd.txt -X \
  set-trust --trustedHost host1 --trustedPort 4444 \
  --modifiedHost host2 --modifiedPort 5444 --trustValue untrusted

dsreplication set-trustコマンドは、対話型モードと非対話型モードの両方でサポートされています。

信頼できるサーバーと信頼できないサーバーの構成には、次の制限があります:

ディレクトリ・サーバーのtrustフラグは、トポロジ内の別の信頼できるサーバーからのみ構成できます。trustフラグは、構成対象のサーバー自体からは構成できません。したがって、-trustedHostオプションと--modifiedHostオプションが同じディレクトリ・サーバーを参照することはできません。
ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、変更対象のホストが稼働中であることが必要です。稼働していないと、コマンドが失敗します。
ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、信頼できない変更が変更対象のホストに存在しないことが必要です。信頼できない変更とは、信頼できないサーバーで行われた変更のことで、そのため、トポロジ内の他のサーバーには伝播されていない変更のことをいいます。変更対象のホストに信頼できない変更がある場合は、トポロジ内のいずれかの信頼できるサーバーの適切なデータ・セットを使用して、影響を受ける接尾辞を再初期化してから、ホストをtrustedに変更してください。
信頼できないサーバーのスキーマを変更すると、そのサーバーを信頼できるサーバーとして再構成できなくなります。この場合、そのサーバー・インスタンスを削除して作成しなおす必要があります。

ディレクトリ・サーバーが信頼できるサーバーか信頼できないサーバーかを調べるには、dsreplication statusコマンドを使用します。たとえば:

$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \
  --hostname host1 --port 4444

32.15.2 分離レプリカのデプロイメント・シナリオの理解

分離レプリカをレプリケーション・トポロジ内で使用して、非武装地帯(DMZ)での追加セキュリティを提供したり、ステージング領域内のクライアント・アプリケーションをテストできます。

分離レプリカをレプリケーション・トポロジ内で使用するための次の2つのシナリオに注意してください。

32.15.2.1 DMZでの分離レプリカの使用について

非武装地帯(DMZ)とは、社内ネットワークの中で、インターネットなどの信頼できないネットワークに公開されている領域のことです。DMZは信頼できるネットワークと信頼できないネットワークの間に位置するため、保護層を備えています。外部からの直接アクセスは、DMZの内側に設置されている機器に限定されます。次の図は、DMZでの分離レプリカの使用方法を示しています。

図32-3 非武装地帯内の分離レプリカ

「図32-3 非武装地帯内の分離レプリカ」の説明

DMZ内に読取り専用ディレクトリ・サーバーを配置することで、危険にさらされているデータが社内ネットワークのプライベート領域内にあるレプリケーション・サーバーに伝播されないようにできます。レプリカをDMZ内にデプロイすると、そのレプリカは社内のファイアウォールで保護されないため、セキュリティが破られる危険性があります。このような場合、不正なユーザーがレプリカの構成にアクセスして、書込み可能なレプリカに変更してしまうおそれがあります。そのため、このようなレプリカに対し、ファイアウォールで保護されているレプリケーション・サーバーは信頼できないというレッテルを貼ります。

DMZ内のサーバーを信頼できないサーバーとして構成することで、悪意のあるデータをそれらのサーバーが受け入れないように保護できます。プライベート領域内のサーバーは、読取りおよび書込みアクセス権を持つように構成されています。この構成により、データ変更がプライベート領域内のディレクトリ・サーバーによってのみレプリケーション・トポロジ全体に伝播されることが保証されます。DMZ内の読取り専用ディレクトリ・サーバーは、プライベート・ネットワークの内側にあるレプリケーション・サーバーからデータ変更を取得します。外部の攻撃者がデータのセキュリティを破ろうとしても、直接アクセス・ポイントはDMZ内の読取り専用サーバーです。DMZ内のディレクトリ・サーバーは信頼できないサーバーなので、悪意のあるデータは伝播できません。したがって、プライベート社内LAN内のサーバー・データの整合性が守られます。

このシナリオには次の構成要件があります:

DMZ内の各ディレクトリ・サーバーが信頼できないサーバーかつ読取り専用として構成されていること。
トポロジ内の各レプリケーション・サーバーがプライベート社内LANの内側に位置していること。
プライベート社内LAN内の各ディレクトリ・サーバーが読取り/書込みアクセス権を持つ信頼できるサーバーとして構成されていること。

トポロジ内の信頼できる各ディレクトリ・サーバーには次のアクセス権が付与されています:

接続先のレプリケーション・サーバーに変更を送信できます。この変更は、トポロジ内の他のすべてのディレクトリ・サーバーに伝播されます。
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができます。

トポロジ内の信頼できない各ディレクトリ・サーバーには次のアクセス制限があります:

接続先のレプリケーション・サーバーに変更を送信する権限がありません。信頼できないディレクトリ・サーバーが変更を送信すると、その変更は危険にさらされたデータと判定され、レプリケーション・サーバーはその変更を破棄します。
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができません。

32.15.2.2 テスト用の分離レプリカについて

ステージング領域でアプリケーションをライブ・データに対してテストするとき、分離レプリカを使用すると便利な場合があります。それには、分離レプリカを信頼できないサーバーとして構成し、読取り/書込みアクセス権を付与します。アプリケーションのアクセス・ポイントは分離レプリカであり、ステージング領域内の分離レプリカにのみデータが書き込まれます。

次の図は、ステージング領域での分離レプリカの使用方法を示しています。

図32-4 ステージング領域内の分離レプリカ

「図32-4 ステージング領域内の分離レプリカ」の説明

32.16 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション

Oracle Directory Server Enterprise EditionのデータをOracle Unified Directoryサーバーにレプリケートするために必要なコンテキスト情報と手順は、これらのトピックで確認してください。

32.16.1 Oracle Directory Server Enterprise EditionとOracle Unified Directoryの間のレプリケーションについて

Oracle Unified Directoryは、Oracle Directory Server Enterprise EditionとOracle Unified Directoryの間でデータをレプリケートする仕組みを備えています。このレプリケーション・ゲートウェイの主な目的は、Oracle Directory Server Enterprise EditionからOracle Unified Directoryへの移行を可能にすることです。

この2つの異なるトポロジ間のレプリケーションを設定するには、次の3つのステップが必要になります:

Oracle Directory Server Enterprise Editionのスキーマおよび構成からOracle Unified Directoryサーバーへの移行。
Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバー間のレプリケーションの構成。
Oracle Directory Server Enterprise EditionサーバーのデータによるOracle Unified Directoryサーバーの初期化。

各ステップについては、次の手順説明を参照してください。これらの手順は、次の作業が完了していることを前提としています:

Oracle Directory Server Enterprise Editionサーバーがインストールされており、稼働中であること。

Oracle Unified Directoryのレプリケーション・ゲートウェイは、DS6モードのパスワード・ポリシーのみをサポートしています。Oracle Directory Server Enterprise EditionのインスタンスでDS5モードのパスワード・ポリシーを使用している場合は、更新する必要があります。
Oracle Unified Directoryディレクトリ・サーバーがインストールされており、稼働中であること。

Oracle Unified Directoryサーバーは、Oracle Directory Server Enterprise Editionサーバーのデータで初期化されるため、接尾辞なしで構成されている必要があります。

レプリケート対象Oracle Unified Directoryトポロジがすでに存在する場合は、Oracle Unified Directoryサーバー・インスタンスをもう1つ接尾辞なしで作成し、そのサーバーをレプリケーション・ゲートウェイにアタッチします。すべてのds2oudコマンドをその空のOracle Unified Directoryサーバーに対して実行する必要があります。Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの間のレプリケーションが稼働しているとき、Oracle Unified Directoryサーバーを既存のレプリケート対象Oracle Unified Directoryトポロジに追加できます。

たとえば、既存のOracle Unified Directoryトポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります。

移行後のサーバー・レイアウトは次のようになります:

32.16.2 Oracle Directory Server Enterprise Editionのスキーマおよび構成の移行

Oracle Unified Directoryでは、すべてのパッチセットが適用されたSun ONE Directory Server 5.2、Sun Java System Directory Server Enterprise Edition 6.3.1、Sun Directory Server Enterprise Edition 7.0およびOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1)の構成とスキーマを移行できます。このタイプのインスタンスの移行は、ds2oudコマンドを使用して実行できます。

これらのバージョンのディレクトリはds2oudツールでのみサポートされていますが、レプリケーション・ゲートウェイ(Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上が必須です)の使用についてこのかぎりではありません。

つまり、移行するインスタンスのバージョンによっては、生成されるOracle Unified Directoryインスタンスが完全に機能するためには、手動での補足のステップが必要になります。たとえば、オブジェクト・クラスおよびパスワード・ポリシーに関するデータの変更やメタデータの変換などです。ただし、Oracle Directory Server Enterprise Edition 11g リリース1 (11.1.1)以上を実行している場合は、この項のステップ2 (2.a)で説明するユーザー・データのエクスポート時に自動的にデータ変換が行われます。

この項の手順では、ds2oudコマンドの様々なオプションについて説明します。コマンド行でds2oudを入力すると、ds2oudコマンドを完全に対話型で実行できます。対話型モードでは、応答を要求するプロンプトが表示されます。詳細は、「ds2oud」を参照してください。

Oracle Directory Server Enterprise Editionディレクトリ・サーバーで、ds2oud --diagnoseコマンドにOracle Directory Server Enterprise Editionサーバーの接続詳細を指定して実行します。ds2oudコマンドは、instance_dir/OUD/bin (Linuxの場合)またはinstance_dir\OUD\bat (Windowsの場合)にあります。

このコマンドは、Oracle Directory Server Enterprise Editionサーバー・インスタンスを評価して、いずれかのサーバー構成をOracle Unified Directoryサーバーに移行する必要があるかどうかを報告します。
```
$ ds2oud --diagnose -h host1.example.com -p 1389 \
  -D "cn=directory manager" -j pwdfile
```
--diagnoseサブコマンドは、Oracle Directory Server Enterprise Editionの次の構成要素を調べます。
- 有効なユーザー・プラグイン
- 有効なサブツリー・エントリ・カウンタ・プラグイン(サブツリー・エントリ・カウンタ・プラグインはOracle Unified Directoryではサポートされていません)
- デフォルトのスキーマに対する拡張
- CoSまたはロール定義
- マクロACI
- ACI構文の妥当性
- パスワード・ポリシーの種類(DS6モードのみがサポートされています)
- データ内の競合するエントリ
- 暗号化された属性(属性の暗号化はOracle Unified Directoryではサポートされていません)
Oracle Unified Directoryスキーマに関するデータのコンプライアンスを検証するには:
1. Oracle Directory Server Enterprise EditionデータをLDIFにエクスポートします。
  
  Oracle Directory Server Enterprise Editionサーバーで、次の例のようにdsconf exportコマンドを実行します。
```
$ dsconf export -f opends-export -h host1.example.com -p 1389 \
  dc=example,dc=com odsee-data.ldif
```
  ノート:
  
  前述のコマンドの-f opends-exportオプションは、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)にのみ適用可能です。
2. データをLDIFにエクスポートしたら、Oracle Unified Directoryでds2oudコマンドを実行します。たとえば:
```
$ ds2oud --ldifDBFile odsee-data.ldif --userSchemaFile 99user.ldif
```
  odsee-data.ldifは、LDIFにエクスポートされたOracle Directory Server Enterprise Editionのデータです。99user.ldifは、Oracle Directory Server Enterprise Editionのカスタマイズされたスキーマ・ファイルです(Oracle Directory Server Enterprise Editionのスキーマをカスタマイズした場合)。
  
  このコマンドは、Oracle Directory Server Enterprise EditionのデータとOracle Unified Directoryのスキーマの間にスキーマの不整合がないかを調べます。データを移行する前に、Oracle Directory Server Enterprise Editionのデータが必要とするスキーマ拡張をOracle Unified Directoryのスキーマに追加する必要があります。
ds2oudコマンドに1つまたは複数の移行オプションを指定して実行し、スキーマ、サーバー構成またはその両方を移行します。

Oracle Unified Directoryがデータを検証できるように、スキーマを移行してから構成を移行する必要があります。
1. ds2oud --migrateUserSchemaを実行すると、Oracle Directory Server Enterprise Editionのユーザー・スキーマ(通常は99user.ldifファイルに格納されています)がOracle Unified Directoryのスキーマに追加されます。
  
  Oracle Unified Directoryの集合属性またはパスワード・ポリシーの機能をレプリケートする計画の場合は、これらの機能のOracle Directory Server Enterprise Editionスキーマを準備する必要があります。Oracle Unified Directoryでは、カスタム・スキーマ・ファイル(99OudSchemaExtract.ldif)がinstall-dir/OracleUnifiedDirectory/config/ds2oudに用意されており、このファイルを使用して、Oracle Unified Directory固有のスキーマ要素をOracle Directory Server Enterprise Editionインスタンスに追加できます。
  
  このスキーマ・ファイルをOracle Directory Server Enterprise Editionスキーマに追加する方法の詳細は、『Oracle Directory Server Enterprise Edition管理ガイド』のカスタム・スキーマ・ファイルによるスキーマの拡張に関する項を参照してください。
2. ds2oud --migrateConfigurationを実行すると、次の操作が行われます:
  - Oracle Directory Server Enterprise Editionの既存の接尾辞に基づいてネーミング・コンテキストが作成されます。ネーミング・コンテキストを単一の共有ワークフロー要素(userRoot)に作成するか、接尾辞ごとのワークフロー要素に作成するかを指定できます。構成にサブ接尾辞が含まれている場合は、強制的に接尾辞ごとのワークフロー要素に作成されます。
  - Oracle Unified Directoryに適用されるいくつかのグローバル構成パラメータ(size-limit、lookthrough-limit、idle-time-limit、max-psearches、bind-with-dn-requires-passwordなど)が移行されます。
  - グローバルおよびバックエンドallidsthresholdパラメータがOracle Unified Directoryのindex-entry-limitバックエンド・プロパティに移行されます。
  - 構成されている索引があれば追加され、索引または索引タイプ上の固有のallidsthresholdパラメータが新しい索引に移行されます。
  - DSE ACIがds-cfg-global-aciに翻訳され、Oracle Unified Directoryの構文検証を使用してACIの妥当性が確認されます。
  - 可能な場合は、7ビット・チェック、UID一意性、参照整合性、強力なパスワード・ポリシー・チェックの各プラグインの構成が移行されます。
  - パスワード・ポリシーが設定され、デフォルトのパスワード・ポリシーがOracle Directory Server Enterprise Editionのデフォルトのパスワード・ポリシーに対応するように構成されます。
    
    ノート:
    
    移行が可能なのは、DS6モードのパスワード・ポリシーを使用しているOracle Directory Server Enterprise Editionサーバーの場合のみです。
3. スキーマおよび構成パラメータを移行するには、次のコマンドを実行します:
```
$ ds2oud --migrateAll -D "cn=directory manager" -j pwdfile \
  -h host1.example.com -p 1389 \
  --oudBindDN "cn=directory manager" --oudBindPasswordFile pwdfile \
  --oudHostname localhost --oudAdminPort 4444 --oudPort 1389
```
  -D、-j、-hおよび-pには、Oracle Directory Server Enterprise Editionインスタンスの接続パラメータを指定します。
  
  ほとんどのACIはエントリ自体に格納されています。したがって、Oracle Directory Server Enterprise EditionインスタンスからデータをエクスポートしてOracle Unified Directoryインスタンスにインポートするときに移行されます。--migrateAllサブコマンドは、構成に格納されているグローバルACIのみを移行します。
  
  Oracle Unified Directoryの構成に関連する追加情報の入力を求められます。このコマンドにより、互換性のある構成がOracle Unified Directoryディレクトリ・サーバー上に作成されます。

32.16.3 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーションの構成

Oracle Directory Server Enterprise EditionとOracle Unified Directoryとの間にレプリケーション・ゲートウェイをインストールして構成する必要があります。

『Oracle Unified Directoryのインストール』のレプリケーション・ゲートウェイの設定に関する項の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。

この時点で、Oracle Unified Directoryサーバーでレプリケーション用のグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象Oracle Unified Directoryトポロジに接続する予定の場合は、他のOracle Unified Directoryサーバーで定義されている同じグローバル管理者の資格証明を使用します。

32.16.4 Oracle Directory Server Enterprise EditionのデータによるOracle Unified Directoryの初期化

Oracle Directory Server Enterprise EditionからレプリケートされたデータをOracle Unified Directoryサーバーで初期化し、レプリケーションをテストできます。

Oracle Unified DirectoryをOracle Directory Server Enterprise Editionのデータで初期化するには:

初期化するOracle Unified Directoryサーバーを準備します。たとえば:

$ dsreplication pre-external-initialization -h localhost -p 4444 \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \
  -X -n --noPropertiesFile

Oracle Directory Server Enterprise Editionサーバーで、次のコマンドを実行してデータ・セットをエクスポートします。
```
$ dsadm export -f opends-export dsee-instance-path baseDN exportedLDIFPath
```
exportedLDIFPathは生成されるLDIFファイルのパスです。このファイルにレプリケート対象データが格納されます。

Oracle Directory Server Enterprise Editionデータに暗号化された属性が含まれている場合は、--decrypt-attrオプションを指定して復号化します。

ノート:

dsadm exportは、LDIF形式のファイルを作成します。

dsadm backupは、Oracle Directory Server Enterprise Editionサーバーのデータベース・ファイルのバイナリ・コピーを作成します。Oracle Directory Server Enterprise EditionとOracle Unified Directoryではデータベースの実装が大きく異なるため、一方のサーバー・タイプからもう一方のサーバー・タイプへデータをエクスポートするときにバイナリ・コピーは使用できません。
ステップ2で生成されたLDIFファイルを、Oracle Unified Directoryサーバーがアクセスできるディレクトリにコピーします。LDIFファイルのファイル権限でサーバーによる読取りアクセスが許可されていることを確認します。
Oracle Unified Directoryサーバーで、次のようにLDIFデータをインポートします。
```
$ import-ldif -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
  --includeBranch dc=example,dc=com --ldifFile path/to/exportedLDIFFile \
  --clearBackend --trustAll --noPropertiesFile
```
ノート:

LDIFファイルの相対パスを使用する場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンスのルートです。したがって、たとえば、imports/odsee-data.ldifというパスはinstance-root/imports/odsee-data.ldifを指します。

移行時にopends-exportオプションを使用すると、DSEE固有の属性が一部のエントリに存在する場合があり、これらのエントリがインポートされないようにできます。たとえば、nds5replconflictがOracle Directory Server Enterprise Editionのデータに存在する場合があります。そのため、Oracle Unified Directoryへのインポート時に、次のインポート・オプションを使用してこの属性をフィルタする必要があります。
```
--excludeAttribute "nsds5replconflict" 
```

Oracle Unified Directoryサーバーで初期化後のスクリプトを実行します。たとえば:

$ dsreplication post-external-initialization -h localhost -p 4444 \
  --adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \
  -X -n --noPropertiesFile

レプリケーションが正常に動作することをテストするために、各Oracle Directory Server Enterprise Editionサーバーで少なくとも1つのエントリを変更し、Oracle Unified Directoryサーバーで変更を確認します。

32.1 レプリケーションを構成する前の前提条件について

32.2 dsreplicationによるデータ・レプリケーションの理解

32.2.1 dsreplicationによる2つのサーバー間のレプリケーションの理解

32.2.1.1 dsreplicationによる2つのサーバー間のレプリケーションの有効化

32.2.1.2 レプリケーション・サーバーの作成場所の制御

32.2.2 dsreplicationによるレプリケート対象サーバーの初期化

32.2.3 dsreplicationによるトポロジ全体の初期化

32.2.4 レプリケート・トポロジのテスト

32.2.5 dsreplicationによるレプリケート・トポロジのステータスの取得

32.2.6 dsreplicationによる既存の2つのレプリケート・トポロジのマージ

32.2.7 dsreplicationによる特定のレプリケーション・ドメインに対するレプリケーションの無効化

32.3 OUDSMを使用したデータ・レプリケーションの構成

32.3.1 OUDSMを更新する場合の考慮事項

32.3.2 既存のレプリケーション・サーバーの構成の表示または変更

32.3.3 レプリケートされた接尾辞の構成の表示または変更

32.3.4 「Directory Manager」タブでのレプリケーション構成ウィザードについて

32.3.4.1 新しいトポロジの最初からの作成

32.3.4.2 既存のトポロジへのサーバーの追加

32.3.5 「トポロジ・マネージャ」タブからのレプリケーション構成ウィザードへのアクセス

32.3.5.1 新しいトポロジの最初からの作成

32.3.5.2 既存のレプリケーション・トポロジの管理

32.4 大規模なレプリケーション・トポロジの構成の理解

32.4.1 大規模なレプリケート・トポロジについて

32.4.2 専用レプリケーション・サーバーの構成

32.5 dsconfigによるレプリケーション構成の変更

32.5.1 レプリケーション・ドメイン名の取得

32.5.2 レプリケーション・パージ遅延の構成

32.5.2.1 レプリケーション変更記録のパージ動作

32.5.2.2 レプリケーション・パージ遅延の変更

32.5.3 ウィンドウ・サイズの構成

32.5.3.1 ウィンドウ・サイズについて

32.5.3.2 ウィンドウ・サイズの変更

32.5.4 初期化ウィンドウ・サイズの構成

32.5.4.1 初期化ウィンドウ・サイズについて

32.5.4.2 初期化ウィンドウ・サイズの変更

32.5.5 ハートビート間隔の構成

32.5.5.1 ハートビート間隔について

32.5.5.2 ハートビート間隔の変更

32.5.6 分離ポリシーの変更

32.5.7 暗号化レプリケーションの構成

32.5.8 レプリケーション・グループの構成

32.5.8.1 レプリケーション・グループについて

32.5.8.2 レプリケーション・グループの構成

32.5.9 保証レプリケーションの構成

32.5.9.1 保証レプリケーション構成について

32.5.9.2 セーフ・データ・モードの保証レプリケーションの構成

32.5.9.3 セーフ読取りモードの保証レプリケーションの構成

32.5.10 部分レプリケーションの構成

32.5.10.1 部分レプリケーション構成について

32.5.10.2 排他部分レプリケーションの構成

32.5.10.3 包含部分レプリケーションの構成

32.5.10.4 部分ドメインの構成および初期化

32.5.11 レプリケーション・ステータスの構成

32.5.11.1 レプリケーション・ステータスにある低下ステータスのしきい値パラメータの構成について

32.5.11.2 低下ステータスのしきい値の構成

32.5.12 レプリケーション・サーバーの重みの構成

32.6 データによるレプリケート対象サーバーの初期化

32.6.1 単一のレプリケート対象サーバーの初期化

32.6.2 新しいレプリケート対象トポロジの初期化

32.6.3 既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加

32.6.4 既存のレプリケート対象トポロジにあるデータ・セットの変更

32.6.5 既存のレプリケート対象トポロジへのデータの追加

32.7 外部変更ログの使用

32.7.1 外部変更ログの有効化

32.7.2 外部変更ログのAPIについて

32.7.3 クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作

32.7.4 外部変更ログ・エントリの形式

32.7.5 外部変更ログに含める属性の指定

32.7.5.1 ecl-includeプロパティを使用した属性の構成

32.7.5.2 ecl-include-del-onlyプロパティを使用した属性の構成

32.7.6 外部変更ログから除外する属性の指定

32.7.7 外部変更ログを使用するクライアント・アプリケーションの初期化

32.7.7.1 外部変更ログを使用するクライアント・アプリケーションの初期化

32.7.7.2 ドメイン追加時のクライアント・アプリケーションの再初期化

32.7.7.3 ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化

32.7.8 外部変更ログへのアクセスの制御

32.7.9 外部変更ログのパージ

32.7.10 サーバーでの外部変更ログの無効化

32.7.11 特定のドメインに対する外部変更ログの無効化

32.7.12 最後の変更番号の取得

32.2 `dsreplication`によるデータ・レプリケーションの理解

32.2.1 `dsreplication`による2つのサーバー間のレプリケーションの理解

32.2.1.1 `dsreplication`による2つのサーバー間のレプリケーションの有効化

32.2.2 `dsreplication`によるレプリケート対象サーバーの初期化

32.2.3 `dsreplication`によるトポロジ全体の初期化

32.2.5 `dsreplication`によるレプリケート・トポロジのステータスの取得

32.2.6 `dsreplication`による既存の2つのレプリケート・トポロジのマージ

32.2.7 `dsreplication`による特定のレプリケーション・ドメインに対するレプリケーションの無効化

32.5 `dsconfig`によるレプリケーション構成の変更

32.7.5.1 `ecl-include`プロパティを使用した属性の構成

32.7.5.2 `ecl-include-del-only`プロパティを使用した属性の構成

32.12 `dsreplication`を使用した証明書の管理

32.12.1 `dsreplication list-certs`を使用した証明書の一覧表示

32.12.2 `dsreplication regenerate-cert`を使用した証明書の再生成

32.12.3 `dsreplication set-cert`を使用した証明書の指定

32.12.4 `dsreplication verify`を使用した証明書の検証と修正

32.13 `verify`サブコマンドの使用

32.13.1 `verify`サブコマンドについて

32.13.2 `dsreplication verify`を使用したレプリケーション構成の検証と修正