test

Sun Java System Directory Server Enterprise Edition 6.3 トラブルシューティングガイド

レプリケーションデータ収集の概要

レプリケーションエラーが発生した場合、レプリケーショントポロジから最小限のデータを収集する必要があります。

レプリケーションのログレベルの設定

アクセスログ、エラーログ、および監査ログ (使用可能な場合) から情報を収集する必要があります。エラーログを収集する前に、レプリケーション情報を保持するためのログレベルを調整します。レプリケーションが含まれるようにエラーログレベルを設定するには、次のコマンドを使用します。


# dsconf set-log-prop ERROR level:err-replication
注 –

Directory Server 5.x で、コンソールを使ってエラーログレベルを設定します。

insync コマンドの使用

insync コマンドは、サプライヤレプリカと 1 つ以上のコンシューマレプリカ間の同期状態に関する情報を提供します。このコマンドは、レプリカの RUV を比較して、サーバー間の時間のずれまたは遅延を秒単位で表示します。

たとえば、次のコマンドは 30 秒ごとに状態を表示します。


$ insync -D cn=admin,cn=Administrators,cn=config -w mypword \
 -s portugal:1389 30

ReplicaDn         Consumer                Supplier        Delay      

dc=example,dc=com france.example.com:2389 portugal:1389   0         

dc=example,dc=com france.example.com:2389 portugal:1389   10         

dc=example,dc=com france.example.com:2389 portugal:1389   0

出力を分析して、レプリケーションの遅延がゼロではなくなる時点を確認します。上の例では、レプリケーションの遅延が 10 に変化しており、コンシューマがサプライヤより 10 秒遅れていることを示しているため、コンシューマ france.example.com とサプライヤ portugal 間でレプリケーションの問題が存在する可能性が見て取れます。この遅延の進み具合を継続的に観察します。この遅延が比較的安定しているか、減少していくようであれば、問題はないと結論できます。しかし、時間の経過とともに遅延が増大していくようであれば、レプリケーションが停止する可能性があります。

insync コマンドの詳細については、insync(1) のマニュアルページを参照してください。

repldisc コマンドの使用

repldisc コマンドは、RUV を使用して既知のレプリカすべてのグラフを作成して、レプリケーショントポロジを表示します。次に、トポロジを表す隣接行列を出力します。このコマンドによりマシン名とその接続が表示されるため、insync ツールの出力を読み取るのが容易になります。Directory Server Version 6.0 以降でこのコマンドを実行するには、次のようにします。


# /opt/SUNWdsee/ds6/bin/repldisc -D cn=Directory Manager -w password -b replica-root -s host:port

Directory Server Version 5.x でこのコマンドを実行するには、次のようにします。


# install-root /shared/bin/repldisc -D cn=Directory Manager -w password -b replica-root -s host:port

次に repldisc コマンドの出力例を示します。


$ repldisc -D cn=admin,cn=Administrators,cn=config -w pwd \
  -b o=rtest -s portugal:1389

Topology for suffix: o=rtest  

Legend:  
^ : Host on row sends to host on column.  
v : Host on row receives from host on column. 
x : Host on row and host on column are in MM mode.  
H1 : france.example.com:1389  
H2 : spain:1389  
H3 : portugal:389

     | H1 | H2 | H3 |
  ===+===============  
H1 |    | ^  |    |  
---+---------------  
H2 | v  |    | ^  |  
---+---------------  
H3 |    | v  |    |  
---+---------------

例: RUV および CSN を使用したレプリケーションの問題のトラブルシューティング

この例では、2 つのマスターが 2 つのホストにレプリケートされて、そこから 5 つのコンシューマにレプリケートされます。

マルチマスターのレプリケーショントポロジ。

レプリケーションは正常に機能せず、致命的なエラーがコンシューマ 4 のログに表示されます。

ただし、レプリケーションはトポロジ規模の機能であるため、トポロジ内のほかのコンシューマでも問題が発生しているかどうかを確認します。コンシューマ 3 と 5 でもエラーログに致命的なエラーが存在していることが判明します。この情報を使って、コンシューマ 3、4、5、ハブ 2 と 3、およびマスター 1 と 2 が問題に関係している可能性があることがわかります。コンシューマ 1 と 2 およびハブ 2 には問題がないと推測できます。

この問題のデバッグを行うには、少なくとも次のレプリケーション参加者から次に示す情報を収集する必要があります。

このデータを使って、遅延の始まりを特定できます。insync コマンドの出力を参照すると、ハブ 2 からの遅延が 3500 秒になっていることがわかります。このため、問題はここから始まった可能性があります。ここで、nsds50ruv 属性の RUV を使って、遅延を発生させた操作を特定できます。トポロジの全域で RUV を参照して、コンシューマに表示された最後の CSN を確認します。この例では、マスター 1 には次の RUV が含まれます。


replica 1: CSN05-1 CSN91-1
replica 2: CSN05-2 CSN50-2

マスター 2 には、次の RUV が含まれます。


replica 2: CSN05-2 CSN50-2
replica 1: CSN05-1 CSN91-1

これらは、完全に同期しているように見えます。ここで、コンシューマ 4 の RUV を参照します。


replica 1: CSN05-1 CSN35-1
replica 2: CSN05-2 CSN50-2

問題は、マスター 1 の CSN 35 に関する変更の次の変更に関係していると考えられます。CSN 35 に関する変更は、これまでコンシューマ 4 にレプリケートされたもっとも古い CSN に対応しています。CSN35–01 上のレプリカのアクセスログに対して grep コマンドを実行することで、問題が発生した時期を特定できます。トラブルシューティングは、この時点から開始してください。

「問題の範囲の定義」で説明したように、問題の発生時点を特定するのに役立つ情報を稼働中のシステムから入手すると有益です。このため、期待どおりに動作しているハブ 1 とコンシューマ 1 からデータを収集します。稼働中のサーバーから得たデータを比較し、問題が発生した時点に注目することで、相違点を識別できます。たとえば、ハブが別のマスターまたはサブネットからレプリケートされていたり、レプリケーションの問題が発生した変更の直前に別の変更がハブに含まれていたりすることがあります。

レプリケーションの問題の考えられる徴候とその対処方法

問題の徴候に応じて、トラブルシューティングの方法も異なります。

たとえば、コンシューマのアクセスログに何も表示されないが、ネットワークの問題が原因でレプリケーション障害が発生することがあります。再初期化は必要ありません。

更新履歴ログ内に特定のエントリが見つからないことがエラーログに示される場合は、マスターの更新履歴ログは最新のものではありません。トポロジの再初期化が必要かどうかは、最新の更新履歴ログがレプリケーショントポロジ (ハブやほかのマスターなど) 内にあるかどうかによります。

ループの処理やロックの中止など、コンシューマで問題が発生した場合は、アクセスログを参照して、特定の CSN で数多く実行されている再試行を見つけます。replck ツールを実行してレプリケーション停止の原因となった CSN を特定し、更新履歴ログ内でこのエントリを修復します。