レプリケーション・トポロジの変更

この項では、既存レプリケーション・トポロジの管理の次の側面について説明します。

レプリケーション・マネージャの変更
レプリケーション承諾の管理
レプリカの昇格と降格
レプリケートされた接尾辞の無効化
レプリケートされた接尾辞の同期の維持

レプリケーション・マネージャの変更

レプリケーション承諾を編集して、コンシューマ・サーバーへのバインドに使用するレプリケーション・マネージャ・アイデンティティを変更できます。レプリケーションが中断されないように、レプリケーション承諾を変更する前に、新しいレプリケーション・マネージャ・エントリまたはコンシューマの証明書エントリを定義する必要があります。バインドの失敗によってレプリケーションが中断された場合、レプリケーション・リカバリ設定の制限内でエラーを修正したときは、レプリケーション・メカニズムによって必要なすべての更新が自動的に送信されます。手順は、「デフォルト以外のレプリケーション・マネージャの使用方法」を参照してください。

レプリケーション承諾の管理

レプリケーション承諾は、無効化、有効化または削除できます。

レプリケーション承諾の無効化

レプリケーション承諾が無効になると、マスターは指定のコンシューマへの更新の送信を停止します。そのサーバーに対するレプリケーションは停止しますが、承諾内の設定はすべて保存されています。後で承諾を再度有効にすることにより、レプリケーションを再開できます。中断後のレプリケーション・メカニズムの再開については、「レプリケーション承諾の有効化」を参照してください。

レプリケーション承諾を無効にするには:

このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。

レプリケーション承諾を無効化します。

$ dsconf disable-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port

たとえば、次のようになります。

$ dsconf disable-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389

レプリケーション承諾の有効化

レプリケーション承諾を有効にすると、指定コンシューマでレプリケーションが再開されます。ただし、レプリケーション・リカバリ設定の許容時間よりもレプリケーション中断時間が長く、別のサプライヤによるそのコンシューマの更新がなかった場合は、そのコンシューマは初期化しなおす必要があります。レプリケーション・リカバリ設定には、サプライヤの変更ログの最大サイズと最大経過時間、およびコンシューマのパージ遅延があります(「詳細コンシューマ構成を実行するには:」を参照)。

中断時間が短く、レプリケーションがリカバリできる場合は、承諾が再度有効になったときにマスターがコンシューマを自動的に更新します。

レプリケーション承諾を有効にするには:

レプリケーション承諾を有効にします。

$ dsconf enable-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port

たとえば、次のようになります。

$ dsconf enable-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389

レプリケーション承諾の削除

レプリケーション承諾を削除すると、対応するコンシューマのレプリケーションは停止され、承諾に関するすべての設定情報が失われます。後日、レプリケーションを再開する場合は、「レプリケーション承諾の無効化」の説明に従って、かわりに承諾を無効にします。

レプリケーション承諾を削除するには:

レプリケーション承諾を削除します。

$ dsconf delete-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port

たとえば、次のようになります。

$ dsconf delete-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389

レプリカの昇格と降格

レプリカの昇格または降格により、レプリケーション・トポロジにおけるレプリカのロールが変化します。専用コンシューマはハブに昇格でき、ハブはマスターに昇格できます。マスターはハブに降格でき、ハブも専用コンシューマに降格できます。ただし、マスターは直接コンシューマには降格できず、同様にコンシューマも直接マスターに昇格できません。

マルチマスター・レプリケーション・メカニズム内で許される昇格および降格により、トポロジがとても柔軟になります。以前はコンシューマ・レプリカにより提供されていたサイトが大きくなると、負荷を処理するため、いくつかのレプリカを持つハブが必要になります。負荷にレプリカの内容に対する変更が多く含まれている場合、ハブはマスターとなり、他のサイトの他のマスターへのレプリケートが可能なより迅速なローカルな変更を行うことができます。

レプリカの昇格または降格時は、次のことに注意してください。

コンシューマを昇格させるとハブになります。ハブを昇格させるとマスターになります。サーバーをコンシューマからマスターに直接昇格させることはできません。まず、コンシューマをハブに昇格させてから、ハブをマスターに昇格させる必要があります。同様に、マスターをコンシューマに降格させる場合、マスターをハブに降格させた後にハブをコンシューマに降格させる必要があります。
マスターをハブに降格させる場合、レプリカは読取り専用となり、残りのマスターにレフェラルを送信するように構成されます。この新しいハブは、そのコンシューマ(ハブまたは専用コンシューマ)をすべて維持します。
シングル・マスターがハブに降格することにより、マスター・レプリカのないトポロジが作成されます。Directory Serverでは、新しいマスターが定義されることを前提に、これが認められます。ただし、新しいマスターをマルチマスターとして追加し、他のマスターを降格させる前に、その新しいマスターを初期化できるようにしておくことをお薦めします。
ハブをコンシューマに降格させる前に、そのハブとのレプリケーション承諾をすべて無効にするか削除する必要があります。これを行わないと、降格操作は、LDAP_OPERATIONS_ERROR “Unable to demote a hub to a read-only replica if some agreements are enabled”というエラーを伴い、失敗することになります。

このハブの下のコンシューマが、他のハブまたはマスターにより更新されていなかった場合、このコンシューマは更新されなくなります。これらのコンシューマが更新されるように、残りのハブまたはマスターに新しい承諾を作成する必要があります。
コンシューマをハブに昇格させると、変更ログが有効になり、コンシューマとの間で新しい承諾を定義できます。
ハブをマスターに昇格させると、レプリカは変更リクエストを受け付けて、他のマスター、ハブまたは専用コンシューマとの間で新しい承諾を定義できます。

レプリカを昇格または降格させるには:

次のコマンドのいずれかを使用して、レプリカを昇格または降格させます。

dsconf promote-repl [-d REPL_ID] SUFFIX_DN [SUFFIX_DN...]

$ dsconf promote-repl -h host -p port [-d REPL_ID] SUFFIX_DN [SUFFIX_DN...]

$ dsconf demote-repl -h host -p port SUFFIX_DN [SUFFIX_DN...]

レプリケートされた接尾辞の無効化

レプリケートされた接尾辞を無効にすると、それはレプリケーション・トポロジから削除されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリケートされたサフィックスは更新されなくなり、更新を送信しなくなります。サプライヤ・サーバーの接尾辞を無効にすると、すべてのレプリケーション承諾が削除され、再びレプリカを有効にするときは、これらの承諾を作成しなおす必要があります。

レプリケートされた接尾辞を無効にするには:

レプリケートされた接尾辞を無効にします。

$ dsconf disable-repl -h host -p port suffix-DN

たとえば、次のようになります。

$ dsconf disable-repl -h host2 -p 1389 dc=example,dc=com

レプリケートされた接尾辞の同期の維持

定期メンテナンスのためにレプリケーションに関わるDirectory Serverを停止させた後、オンラインに戻す場合、レプリケーションによってただちに更新されるようにする必要があります。マルチマスター環境のマスターの場合、マルチマスターセットのもう一つのサーバーからディレクトリ情報を更新する必要があります。マルチマスター以外の環境でも、ハブ・サーバーや専用コンシューマ・サーバーがメンテナンスのためにオフラインとなった後、オンラインに復帰したときには、マスター・サーバーによりそれらを更新する必要があります。

この項では、レプリケーションの再試行アルゴリズムおよび、次回の再試行まで待たずに強制的にレプリケーション更新を行う方法を説明します。

注意: ここで説明されている手順を利用できるのは、レプリケーションの設定が完了し、かつコンシューマが初期化済である場合に限ります。

レプリケーション再試行のアルゴリズム

ソース・レプリカのターゲットへのレプリケーションが失敗すると、間隔を増加させながら定期的に再試行が行われます。再試行の間隔はエラー・タイプにより異なります。

ソース・レプリカとターゲット・レプリカの間で、常に同期をとるレプリケーション承諾を設定していても、オフライン状態の時間が5分を超えたレプリカをただちに更新するには、この方法では不十分です。

レプリケーションの更新を強制するには:

レプリケーションを停止した場合、ターゲットの接尾辞に対して、レプリケーションの更新を強制的に実行できます。

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

ソース・サーバーで、ターゲット・サーバーに対するレプリケーション更新を再起動します。
```
$ dsconf update-repl-dest-now -h host -p port suffix-DN destination-host:destination-port
```
たとえば、次のようになります。
```
$ dsconf update-repl-dest-now -h host2 -p 1389 dc=example,dc=com host1:1389
```

新しいマシンへのマスター・レプリカの移動

状況によっては、マスター・レプリカを別のマシンへ移動することが必要になる場合があります。同じホスト名およびポート番号を使用する必要がない場合、dsconf change-repl-destを使用してリモート・レプリカのホスト名とポート番号を変更します。詳細は、「レプリケーション承諾の対象を変更するには:」を参照してください。

同じホスト名およびポート番号を維持する必要がある場合は、既存のトポロジからマスターを削除した後、トポロジにマスターを再度追加する必要があります。

DSCCでは、影響を受けるレプリケーション承諾をすべて管理しているので、DSCCを使用してこの作業を実行するほうがずっと簡単です。ただし、DSCCを使用する場合、マスターがトポロジで元々持っていたものと同じレプリカIDは指定できません。同じレプリカIDを使用するには、次のようにコマンドラインを使用して、これらのタスクを実行する必要があります。

既存レプリケーション・トポロジからマスターを削除するには:

始める前に

マスターからのすべての変更がレプリケート済であることを確認します。

可能であれば、バイナリ・コピーを使用してマスターのバックアップを行い、変更が失われないようにします。
マスター・レプリカをハブ・レプリカに降格させます。
「レプリカの昇格と降格」を参照してください。
ハブが他のサーバーに対するレプリケートを開始するのを待ちます。
ハブがトポロジ内の他のサーバーに対してレプリケーション・セッションを開くと、そのセッションはRUVに残りますが、レフェラルでは使用されなくなります。
ハブを停止します。
「Directory Serverインスタンスの起動、停止および再起動」を参照してください。
トポロジからハブを削除します。
「レプリケートされた接尾辞の無効化」を参照してください。

既存レプリケーション・トポロジにマスターを追加するには:

同じレプリカIDを使用して、マスター・レプリカを追加します。
「マスター・レプリカでのレプリケーションの有効化」を参照してください。
このマスターからトポロジ内の他のレプリカへのレプリケーション承諾を再度作成します。
新しいマスターを初期化します。
1. マスターのバックアップが可能だった場合は、そのバックアップから新しいマスターを初期化します。
2. マスターのバックアップができなかった場合(マシン・クラッシュの場合)は、トポロジ内の別のマスターからマスターを初期化します。

ナビゲーション・リンクをスキップ
印刷ビューの終了
	Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)