test

Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド

レプリケートされたサフィックスの復元

サプライヤサーバーとコンシューマサーバーの間でレプリケートされるサフィックスを復元する場合は、特別な注意が必要です。可能な場合は、サフィックスをバックアップから復元するのではなく、レプリケーションメカニズムにより更新するようにしてください。

サプライヤまたはハブインスタンスを復元する場合、サーバーはバックアップ時と同じ設定にする必要があります。これを確実に実行するには、Directory Server データを復元する前に、dse.ldif ファイルを復元します。「dse.ldif 設定ファイルの復元」を参照してください。

ここでは、レプリカを復元すべき場合とその方法、および復元後にほかのレプリカとの同期を確保する方法について説明します。レプリカの初期化については、「レプリカの初期化」を参照してください。

レプリケートされたサフィックスが大規模で、多数のエントリを追加し、レプリケーションの更新を確実に正しく追加されるようにする場合は、「大量のレプリケートされたサフィックスへの多数のエントリの段階的追加」を参照してください。

この節では、次の情報について説明します。

シングルマスターモデルでのサプライヤの復元

シングルマスターサプライヤであるサフィックスには、レプリケーショントポロジ全体に対して重要なデータ (authoritative data) が含まれています。したがって、このサフィックスを復元することは、トポロジ全体のすべてのデータを初期化し直すことと同じです。シングルマスターを復元するのは、復元するバックアップの内容ですべてのデータを初期化し直す場合に限定してください。

エラーのためにシングルマスターのデータを復旧できない場合は、コンシューマ上のデータを使用することも検討してください。これは、バックアップされたデータより新しい更新がコンシューマ上のデータに含まれている可能性があるためです。この場合は、コンシューマレプリカから LDIF ファイルにデータをエクスポートし、この LDIF ファイルを使用してマスターを初期化し直します。

バックアップから復元する場合でも、LDIF ファイルをインポートする場合でも、このマスターレプリカから更新を受け取るすべてのハブレプリカとコンシューマレプリカをあとで初期化し直す必要があります。コンシューマの再初期化が必要であることを示すメッセージが、サプライヤサーバーのログファイルに記録されます。

マルチマスターモデルでのサプライヤの復元

マルチマスターレプリケーションでは、ほかの各マスターも、レプリケートされるデータに対してコピーする権限を持っています。現在のレプリカの内容が反映されていない可能性があるため、古いバックアップを復元することはできません。可能な場合は、レプリケーションメカニズムにより、ほかのマスターの内容を使用してマスターを更新するようにしてください。

それが不可能な場合は、次のどちらかの方法でマルチマスターレプリカを復元してください。

復元や再初期化の方法にかかわらず、初期化後のマスターレプリカは読み取り専用モードになります。この動作により、このレプリカとほかのマスターとの同期をとったあとに、書き込み操作を許可できます。詳細は、「マルチマスターモデルでのマスターの復元」を参照してください。

復元または初期化し直したマスターに書き込み操作を許可する前に、すべてのレプリカを反映させることができるので、ハブサーバーやコンシューマサーバーを初期化し直すことが不要になるという利点があります。

ハブの復元

この節の内容は、レプリケーションメカニズムで自動的にハブレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、ハブレプリカを復元または初期化し直す必要があります。

注 –

ハブレプリカの復元や再初期化の方法にかかわらず、あとでこのハブのコンシューマをすべて初期化し直す必要があります。ほかのレベルのハブもすべて初期化し直す必要があります。

専用コンシューマの復元

この節の内容は、レプリケーションメカニズムで自動的に専用コンシューマレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、コンシューマを復元または初期化し直す必要があります。

マルチマスターモデルでのマスターの復元

マルチマスターレプリケーションでは、あるマスターの復元中に他のマスターが変更を処理することもあります。このため、復元が完了した時点で、新しいマスターは復元データに含まれていなかった新しい更新を受け取る必要があります。マスターの復元には時間がかかるため、その間に発生する未適用の更新の数も問題となることがあります。

これらの未適用更新が適用されるように、新たに復元されたマスターは、復元後、クライアント側からの操作に対して自動的に読み取り専用モードに設定されます。これは、コマンド行で LDIF ファイルからデータをインポートするか、バックアップを使用してバイナリコピーを実行することで、マスターを復元する場合のみに当てはまります。

したがって、マルチマスター設定の復元後のマスターは、レプリケーションの更新を処理し、クライアントからの読み取り操作を受け付けますが、すべての書き込み操作に対してはリフェラルを返します。

更新を許可する前に、新しいマスターがほかのマスターと完全に同期していることを確認するには、初期化されたマスターを手動で更新できるようにします。

注 –

この新しい対応方法によってマスターレプリカがリフェラルを送信する場合、書き込み処理を待機しているクライアントのホップ回数が、制限回数に達してしまうことも考えられます。利用可能なマスターにアクセスできるように、クライアントのホップ制限の設定を変更する必要があるかもしれません。すべてのマスターレプリカを初期化または再初期化するときは、どのレプリカもクライアントからの更新を受け付けられないため、すべての書き込み処理が失敗します。

サーバーの応答を最大化するには、いかなる場合も初期化したマスターを注意深く監視し、リフェラルの属性を適切に設定してください。

Procedureコマンド行による更新の受け付けを開始する

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

次のコマンドは、マルチマスターレプリカの初期化プロセスを自動化するスクリプトで使用できます。

  1. insync ツールを使用して、レプリカの状態が他のすべてのマスターと一致していることを確認します。

    すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、insync(1) のマニュアルページを参照してください。

  2. 更新の受け付けを始めます。


    $ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on

    このコマンドは、サーバーを自動的に読み書きモードに設定します。