ここでは、既存のレプリケーショントポロジの管理の以下の側面について説明します。
レプリケーションアグリーメントを編集して、コンシューマサーバーへのバインドに使われるレプリケーションマネージャーの識別情報を変更できます。レプリケーションが中断されないように、レプリケーションアグリーメントを変更する前に、新しいレプリケーションマネージャーエントリまたはコンシューマの証明書エントリを定義する必要があります。ただし、バインドの失敗によってレプリケーションが中断された場合、レプリケーション回復設定の制限内でエラーを修正したときは、レプリケーションメカニズムによって必要なすべての更新が自動的に送信されます。手順については、「デフォルト以外のレプリケーションマネージャーの使用」を参照してください。
レプリケーションアグリーメントを無効化、有効化、または削除できます。
レプリケーションアグリーメントを無効にすると、そのアグリーメントに指定されているコンシューマに対してマスターが更新を送信しなくなります。そのサーバーのレプリケーションは停止されますが、アグリーメントに記録されているすべての設定は残されます。あとからまたアグリーメントを有効にすることで、レプリケーションを再開できます。中断後にレプリケーションメカニズムを再開することについては、「レプリケーションアグリーメントの有効化」を参照してください。
このタスクは 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 |
レプリケーションアグリーメントを有効にすると、指定のコンシューマのレプリケーションが再開されます。ただし、レプリケーションの回復設定で許容される時間より長くレプリケーションを中断していた場合は、別のサプライヤによるコンシューマの更新が行われないため、コンシューマを初期化し直す必要があります。レプリケーションの回復設定は、最大サイズとこのサプライヤの更新履歴ログの経過時間とコンシューマの削除の遅延です (「コンシューマの詳細設定を行う」を参照)。
中断時間が短く、レプリケーションが回復された場合は、アグリーメントがふたたび有効になったときに、マスターが自動的にそのコンシューマを更新します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
レプリケーションアグリーメントを有効にします。
$ 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 |
レプリケーションアグリーメントを削除すると、対応するコンシューマのレプリケーションは停止され、アグリーメントに関するすべての設定情報が失われます。後日レプリケーションを再開する場合は、「レプリケーションアグリーメントの無効化」で説明するように、アグリーメントを無効にします。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
レプリケーションアグリーメントを削除します。
$ 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”。
そのハブのコンシューマが他のハブまたはマスターによって更新されるように設定されていない場合、そのコンシューマは更新されなくなります。これらのコンシューマが更新されるように、残りのハブまたはマスターに新しいアグリーメントを作成する必要があります。
コンシューマをハブに昇格させると、更新履歴ログが有効になり、コンシューマとの間に新しいアグリーメントを定義できるようになります。
ハブをマスターに昇格させると、レプリカは更新要求を受け付けるようになり、他のマスター、ハブ、または専用コンシューマとの間に新しいアグリーメントを定義できるようになります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
レプリカの役割を変更するには、次のいずれかのコマンドを使用します。
$ dsconf promote-repl -h host -p port role suffix-DN |
$ dsconf demote-repl -h host -p port role suffix-DN |
role は master、 hub、または consumer です。
レプリケートされたサフィックスを無効にすると、それはレプリケーショントポロジから除外されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリケートされたサフィックスは更新されなくなり、更新を送信しなくなります。サプライヤサーバーのサフィックスを無効にすると、すべてのレプリケーションアグリーメントが削除されます。そのレプリカをふたたび有効にするときは、これらのアグリーメントを作成し直す必要があります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
レプリケートされたサフィックスを無効にします。
$ 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 を使用して、マスターレプリカを追加します。
「マスターレプリカ上でのレプリケーションの有効化」を参照してください。
そのマスターからトポロジのほかのマスターにレプリケーションアグリーメントを再作成します。
新しいマスターを初期化します。