この節では、レプリケーション停止およびレプリケーション不一致のトラブルシューティングを行う方法について説明します。次の項目について説明します。
レプリケーション停止は、次のいずれかが原因で引き起こされることがあります。
レプリケーションアグリーメントが無効であるか、存在しない
サプライヤの更新履歴ログに更新履歴が欠落している
サプライヤの更新履歴ログのキャッシュが破損している
レプリケーションマネージャーが無効な資格を使用している
レプリケーションが停止状態のスレッドを送信している
スキーマが競合している
URP (Update Resolution Protocol) が競合するために操作がコンシューマ上で許可されていない
ネットワークが接続されていない
使用不可のサプライヤによりコンシューマの状態がロックダウンしている
コンシューマのディスクの空き容量が不足している
RUV に ffff, cleanruv などの無意味の情報が含まれる
レプリケーション不一致は、次のいずれかが原因で引き起こされることがあります。
コンシューマの能力がサプライヤの能力よりも劣っている
コンシューマのディスクが読み取り/書き込み制限の上限に達している
断続的なネットワークとパケット欠落の問題がある
更新履歴ログのメモリー内キャッシュが使用されていない
この節では、レプリケーション停止またはレプリケーション不一致のトラブルシューティングに役立つ情報の収集方法について説明します。
変更を取得していないコンシューマおよびこのコンシューマのサプライヤからエラーログを収集します。デフォルトでは、エラーログは次のディレクトリ内にあります。
install-path/logs/errors |
エラーログがデフォルトの場所に存在しない場合、次のように dsconf コマンドを使用してログのパスを検索します。
# dsconf get-log-prop -h host -p port ERROR path |
エラーログのレプリケーションログレベルを有効に設定している必要があります。レプリケーションログレベルを有効にするには、DSCC を使用するか、次のようにコマンド行を使用します。
# dsconf set-log-prop -h host -p port ERROR level:err-replication |
また、データベースと同じディレクトリ内にあるサプライヤの更新履歴ログのリストも指定してください。データベースのパスを検索するには、dsconf コマンドを次のように使用します。
# dsconf get-suffix-prop -h host -p port suffix-dn db-path |
次のコマンドを使用して、サプライヤの更新履歴ログディレクトリを指定します。
# ls -la /db-path/c15* |
Directory Server 5.x 以前のバージョンでは、エラーログは次のディレクトリ内にあります。
install-path/slapd-serverID/logs/errors |
エラーログファイルがデフォルトの場所に存在しない場合は、Directory Server 設定ファイル install-path/slapd-serverID /config/dse.ldif でログのパスを検索します。パスは、nsslapd-errorlog 属性の値として指定されています。
サプライヤの更新履歴ログディレクトリのリストを、次のように指定します。
# ls -la changelog-dir |
更新履歴ログファイルがデフォルトの場所に存在しない場合は、Directory Server 設定ファイル install-path/slapd-serverID /config/dse.ldif でログのパスを検索します。パスは、nsslapd-changelogdir 属性の値として指定されています。
insync および repldisc コマンドの出力を、レプリケーション不一致のトラブルシューティングに役立てます。
insync コマンドは、マスターレプリカと 1 つ以上のコンシューマレプリカ間の同期状態を示します。この情報をボトルネックの特定に活用できます。レプリケーション不一致の問題を解決するには、このデータを定期的に取得する必要があります。詳細は、「insync コマンドの使用」を参照してください。
insync コマンドを使用してボトルネックを検出した場合 (たとえば、このツールの出力からボトルネックが遅延の増加によるものであることがわかった場合)、nsds50ruv および ds6ruv 属性データの収集を開始することが役立ちます。このデータは、停止する可能性のある時点および場所を特定するのに役立ちます。nsds50ruv および ds6ruv 属性の詳細については、「レプリカ更新ベクトル (RUV) について」を参照してください。
repldisc コマンドは、既知のレプリカすべてのグラフを作成してから結果を行列で表示して、レプリケーショントポロジを示します。詳細は、「repldisc コマンドの使用」を参照してください。
次に示すように、コンシューマとサプライヤの両方で netstat コマンドを実行して、レプリケーションの停止がネットワークに起因するものかどうかの判別を試みます。
# netstat -an | grep port |
アクセスログにサプライヤが更新を送信していることが表示されているにもかかわらず、コンシューマが情報を受信していない場合は、レプリケーション停止の原因がネットワークにある可能性があります。ping および traceroute コマンドを実行すると、ネットワークレイテンシが問題の原因であるかどうかを判別するのに役立ちます。
スワップ情報を収集して、メモリーが不足しているかどうかを確認します。swap コマンドの出力が小さい場合は、メモリーが問題の原因である可能性があります。
Solaris |
swap -l |
HP-UX |
swapinfo |
Linux |
free |
Windows |
C:\report.txt に提供済み |
ディスクコントローラが完全にロードされているかどうか、および入力/出力がレプリケーションの問題の原因かどうかの判別を試みます。ディスクに問題があるかどうかを判別するには、次のように iostat ツールを使用します。
# iostat -xnMCz -T d 10 |
iostat コマンドは、端末、ディスク、およびテープの入力/出力アクティビティーを反復的に報告します。この情報は、レプリケーション不一致イベントがコンシューマ側ディスクの飽和状態に起因するかどうかを判別するのに役立ちます。
収集したデータを使って、レプリケーション停止の原因がサプライヤまたはコンシューマの問題であるかどうかを判別します。
収集した nsds50ruv 属性の出力を使って、特定のコンシューマにレプリケートされた最後の CSN を特定します。次に、コンシューマのアクセルログとエラーログ (レプリケーションレベルの出力を収集するように設定されたログ) を使用して、レプリケートされた最後の CSN を特定します。この CSN から、レプリケーションプロセスが提供に失敗した、その次の CSN を特定できます。たとえば、レプリケーションが失敗する原因として、サプライヤが CSN をレプリケートしていない、ネットワークが CSN をブロックしている、またはコンシューマが更新の受け入れを拒否していることが考えられます。
コンシューマ上で CSN を更新できない可能性があります。次に示すように grep を使用して、サプライヤがコンシューマ上で更新できない CSN を検索します。
grep csn=xxxxxxxx consumer-access-log |
CSN が見つからない場合は、現在失敗しているサプライヤおよびコンシューマにコミットされた CSN のうち、以前に成功したものを検索してみます。CSN を使用して、エラーの検索範囲を絞り込むことができます。
grep コマンドを使用してアクセスログおよびエラーログ内で CSN を検索することで、エラーが単なる一過性のものかどうかを判別できます。必ず、エラーログ内のエラーメッセージを対応するアクセスログアクティビティーと一致させてください。
分析により、レプリケーションが常に同一の CSN 内で、etime=0 および err=32 または err=16 でループしていることが明らかになる場合、レプリケーションの停止が致命的なエラーである可能性があります。レプリケーション停止がコンシューマ上の問題に起因する場合は、replck ツールを実行して物理データベース内のループしているエントリにパッチを適用することで、問題を修正できます。
分析の結果、コンシューマログ内にレプリケーションの CSN の報告がないことが判明した場合は、サプライヤ側またはネットワークの問題が原因である可能性があります。問題の原因がサプライヤにある場合は、レプリケーションアグリーメントでリモートレプリカに強制的に更新を送信するようにするか、サプライヤを再起動することにより、レプリケーションを再開できることがます。それ以外の場合、再初期化が必要になる可能性があります。
ローカルサフィックスからリモートレプリカへの更新を強制的に実行するには、次のコマンドを使用します。
# dsconf update-repl-dest-now -h host -p port suffix-DN host:port |
|
エラーログに含まれるメッセージからスキーマに問題があることがわかった場合は、スキーマ関連の情報をさらに収集します。サプライヤからコンシューマに変更を送信する前に、サプライヤは変更がスキーマに従っていることを確認します。エントリがスキーマに準拠していない状態で、サプライヤがこのエントリの更新を試みる場合に、ループが発生することがあります。
スキーマが原因で発生した問題を修正するには、スキーマのマスター参照として動作可能なサプライヤを 1 つ入手します。/install-path/config/schema ディレクトリの内容を取得します。次の方法で、ディレクトリを 1 つのファイルにまとめます。
# tar -cvs schema schema.tar |
FTP を使用して、この tar ファイルをトポロジ内のほかのすべてのサプライヤおよびコンシューマにエクスポートします。各サーバーの /install-path/config/schema ディレクトリを削除して、マスタースキーマ参照上で作成した tar ファイルで置き換えます。
iostat ツールの出力を使用して、レプリケーション不一致の原因がコンシューマのディスクパフォーマンス低下にあるかどうかを確認します。ディスクパフォーマンスの問題診断の詳細については、「例: RUV および CSN を使用したレプリケーションの問題のトラブルシューティング」を参照してください。
レプリケーション不一致の原因は、通常は次のいずれかです。
サプライヤからコンシューマへのデータ送信が、十分な速度で実行されていません。たとえば、サプライヤの更新履歴ログから、メモリー内キャッシュの設定が低いことが明らかになることがあります。これらの設定を確認するには、cn=changelog5,cn=config エントリ内の nsslapd-cachememsize および nslapd-cachesize 属性値を参照します。
nsslapd-cachememsize 属性は、更新履歴ログまたはデータベース、使用可能なメモリー容量に基づくキャッシュサイズを指定します。nslapd-cachesize 属性は、レプリケーション更新履歴ログまたはデータベース、保持可能なエントリ数に基づくキャッシュサイズを指定します。
ネットワークの容量が不十分で、更新の生成速度に対応した転送速度を保証できません。ネットワークが非常に狭い帯域幅で機能している場合、ネットワークの容量が問題になります。
Directory Server 5.1 では、ネットワークレイテンシが大きすぎて、更新が生成される速度での転送を保証できません。レプリケーション転送プロトコルは同期的であるため、Directory Server 5.1 では、ネットワークレイテンシに起因する問題が発生することがあります。
コンシューマの速度が遅いため、受信する変更を適用できません。たとえば、ディスク使用率が飽和状態にあるか、レプリケーションの並列実行時 (インデックスを使用しない検索など) に問題が発生した場合に、コンシューマの速度が問題になることがあります。
Directory Server Version 5.1 を使用していて、レプリケーション不一致が発生した場合は、プロトコルの制限が原因である可能性があります。5.1 でのレプリケーションは同期的であるため、WAN 経由でのレプリケーションはサポートされていません。WAN 経由でのレプリケーションを行う場合は、アップグレードする必要があります。
LAN 経由でレプリケートする場合は、ping コマンドを使用してサプライヤとコンシューマ間のネットワークレイテンシを確認します。Directory Server Version 5.1 では、サプライヤは、コンシューマからの確認応答を受信してからでないと変更を送信できません。その結果、交換速度が遅い場合に、コンシューマのダウンタイムが発生します。ダウンタイムは停止に似ていますが、実際は交換速度が遅いだけです。たとえば、パスワードをアップグレードする場合、新しいパスワードはすぐに有効にならないために、レプリケーション不一致が発生したかのような印象を受けることがあります。サプライヤのアクセスログを分析して、受信する更新の数を秒ごとに確認します。たとえば、サプライヤのアクセスログには、さまざまなトラフィックが秒ごとに表示されます。次に例を示します。
13:07:04 14 13:07:05 10 13:07:06 15 13:07:07 5 |
次に、コンシューマのアクセスログを参照します。アクセスログに連続した更新が表示される場合、それがボトルネックであることがわかります。
13:07:04 8 13:07:05 8 13:07:06 8 13:07:07 8 |
この種の問題が起きている場合は、ネットワークアクセス、帯域幅、または小規模なリンクが原因である可能性があります。
上級ユーザーは、replcheck ツールを使って Directory Server 6.x のレプリケーションを確認および修復できます。このツールを使用する際は、Sun サポートのアドバイスに従うことを強くお勧めします。Sun サポートは、このツールで収集した有用な情報を使って、問題を分析したり、さまざまなタイプのレプリケーション停止を直接修復したりできます。このツールは、 install-path/ds6/support_tools/bin/ ディレクトリにあります。
以前のバージョンの replcheck ツールは、Directory Server 5.x で使用できます。詳細は、Sun サポートにお問い合わせください。
replcheck コマンドの詳細については、replcheck(1M) を参照してください。
診断モードで実行する場合、replcheck ツールはレプリケーション切断の原因を診断して、推奨する修復処理の概要を示します。このツールは、レプリケーショントポロジ内の各サーバーの RUV を比較して、マスターが同期しているかどうかを確認します。検索結果から、すべてのコンシューマレプリカのメモリー内 RUV が定時に展開されるか、展開されないがサプライヤレプリカの RUV と等価であることが判明すると、このツールはレプリケーションの停止が発生していないと結論します。
レプリケーションの問題を診断するには、次のように replcheck ツールを実行します。
replcheck diagnose topology-file |
topology-file には、ファイルのパスを指定します。次に示す書式に従って、各行に 1 つのレコードを含めます。 hostname:port:suffix_dn[: label]。オプションの label フィールドには、表示またはログに記録されるメッセージに表示される名前を指定します。label を指定しない場合、hostname : port が代わりに使用されます。
たとえば、次のトポロジファイルは、2 つのホストで構成されるレプリケーショントポロジを表します。
host1:389:dc=example,dc=com:Paris host2:489:dc=example,dc=com:New York |
replcheck diagnose コマンドによってレプリケーション停止が発生していることを確認したら、replcheck fix サブコマンドを使ってレプリケーション停止を修復できます。たとえば、サプライヤが CSN 40 を保持し、コンシューマの保持する CSN 23 は時間が経過しても展開されない場合、このコマンドは CSN 24 に関連するエントリ上でレプリケーションがブロックされたと判断します。
レプリケーション停止を修復するには、次に示すように replcheck fix コマンドを実行します。
replcheck fix TOPOLOGY_FILE |