test

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

第 3 章 レプリケーションのトラブルシューティング

この章では、レプリケーションに関する問題のトラブルシューティングに役立つ情報を示します。また、トポロジ全体の再初期化に役立つ手順についても説明します。この章は、次の各節で構成されています。

レプリケーションの問題の分析

この節では、レプリケーションに関する問題の一般的な分析手順を紹介します。レプリケーションの動作方法およびレプリケーションデータの収集に使用可能なツールについて説明します。

レプリケーションについて

レプリケーションは、複数の参加者が関与するトポロジ規模の機能です。この理由で、レプリケーションに関する問題のトラブルシューティングでは、トポロジ内でレプリケーションが停止したポイント、および破壊されたレプリケーションアグリーメントを確認する必要があります。

レプリケーションは次のように動作します。

  1. マスターが変更を受信します。変更がデータベース内のエントリに適用されると、サーバーがマスターであるため、サーバーにより更新履歴ログデータベース内に変更が格納されます。

  2. マスターが、メモリー内のレプリカ更新ベクトル (RUV) を更新します。

  3. マスターが、新しい変更が更新履歴ログに記録されたことをレプリケーションスレッドに通知します。

  4. これらのレプリケーションスレッドは、レプリケーションパートナーと通信して情報を伝達します。

たとえば、マスター 1 は変更を受信し、エントリに適用して、更新履歴ログを更新します。マスター 1 上のスレッドがコンシューマと通信すると、コンシューマは自身の RUV 情報をマスターに示します。マスターは RUV を参照してメモリー内部の RUV と比較し、コンシューマよりも新しい変更が含まれるかどうかを確認します。たとえば、コンシューマの RUV の方が新しい情報を持っている場合は、変更を送信しません。マスターに新しい変更が含まれる場合、マスターは更新を実行できるように、レプリカ ID 1 のロックを求める別の要求をコンシューマに送信します。ロックできない場合は、更新は延期されます。ロック可能な場合、マスターは変更の処理に進むことができます。

変更シーケンス番号 (CSN) について

レプリケーションは逐次的です。つまり、エントリのレプリケーションは順番に実行されます。レプリケーションは順番に実行されるため、マスターにより生成されたすべての変更に、変更シーケンス番号 (CSN) が付けられます。この番号は、マルチマスタートポロジ内部のすべての変更で一意です。CSN は 16 進数で、次のようにログに表示されます。


41e6ee93000e00640000

この 16 進数の最初の 8 桁は、マスターで変更が生成された時刻を表します。時刻は、1970 年 1 月 1 日からの経過時間 (秒) で表されます。

次の 4 桁は、シーケンス番号、つまり現在の秒で変更が発生した順番です。たとえば、秒 41e6ee93 の間に複数の変更が発生する場合があります。シーケンス番号は、この秒のどの時点で変更が発生したかを示します。

次の 4 桁は、最初に変更を受信したマスターのレプリカ ID を示します。

最後の 4 桁は常に 0000 になります。

CSN が生成されるのは、ローカルトラフィックによって新しい変更がレプリカに取り込まれるときだけです。このため、更新を受信するマスターだけが CSN を生成します。受信する更新はすべてレプリケーションを介して実行されるため、コンシューマは常にマスターを参照します。

トラブルシューティングの際は、遅延の原因となった CSN を検索してみてください。遅延に関係する CSN を検索するには、レプリカ更新ベクトル (RUV) を使用する必要があります。RUV については、次の節で説明します。

レプリカ更新ベクトル (RUV) について

レプリケーショントポロジ内のすべてのレプリカは、現在のレプリケーション状態をレプリカ更新ベクトル (RUV) に格納します。RUV は、実行中のプロセスによりメモリー内に格納され、このレプリカが保持する自分自身およびレプリケーショントポロジ内のほかの参加者すべての正確な情報を提供します。指定されたサーバーの RUV エントリの各行には、レプリケーショントポロジに参加しているマスターが含まれます。各行には、いずれかのマスターの識別子、レプリカの URL、およびサーバーで実行された最初と最後の変更の CSN が含まれます。CSN には、サーバーが検出した最初と最後の変更だけが記録されます。マスターにより実行された最新の変更が記録されるとは限りません。

RUV エントリの状態は、次に示すエントリ内で 30 秒ごとに物理的に更新されます。


nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,suffix-name

RUV はメモリーにも格納されます。この RUV にアクセスするには、cn=replica,cn=suffix,cn=mapping tree,cn=config エントリに対して ldapsearch を使用します。たとえば、ldapsearch を ou=people サフィックスに対して実行すると、次のような結果が生成されます。


# ldapsearch -h host1 -p 1389 -D cn=Directory Manager -w secret \
-b cn=replica, 
cn=ou=people,cn=mapping tree,cn=config -s base objectclass=* nsds50ruv
nsds50ruv: {replicageneration} 45e8296c000000010000
nsds50ruv: {replica 1 ldap://server1:1389} 45ed8751000000010000 4600f252000000010000
nsds50ruv: {replica 2 ldap://server1:2389} 45eec0e1000000020000 45f03214000000020000

わかりやすいように、ここからは RUV の構文を CSNchange-number -replica-id に簡略化します。change-number は、マスターで発生した一連の変更のうち、どの変更が RUV に対応するかを示します。たとえば、45ed8751000000010000 は CSN05-1 と記述できます。前の例では、マスター 1 には次の RUV が含まれています。


replica 1: CSN05-1 CSN43-1
replica 2: CSN05-2 CSN40-2

最初の行は、レプリカ ID 1 で示されるこのレプリカ自身 (マスター 1) から入手した、このレプリカが認識している最初と最後の変更の情報を示します。2 番目の行は、マスター 2 から入手した、このレプリカが認識している最初と最後の変更の情報を示します。注目すべき情報は、最後の変更の方です。通常の操作では、受信した更新についてマスター 1 はマスター 2 より多くの情報を持っています。この点をマスター 2 の RUV で確認してみましょう。


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

最後の変更を参照すると、マスター 2 は受信した最後の変更 (CSN50-2) について、マスター 1 (最後の変更が CSN40-2 で発生したとしている) より多くの情報を持っていることがわかります。それに対して、マスター 1 はその最後の変更 (CSN43-1) について、マスター 2 (CSN35-1) より多くの情報を持っています。

レプリケーションの問題のトラブルシューティングでは、CSN は問題を識別するのに役立ちます。マスター 1 は常に、自身のレプリカ ID について、レプリケーショントポロジ内のほかの参加者と同程度以上の情報を持っています。変更は最初にマスター 1 に適用されてからレプリケートされるからです。このため、CSN43-1 は、トポロジ内のレプリカ ID 1 に関連付けられる最大の値になります。

たとえば、30 分後にマスター 1 上の RUV が依然として CSN40-2 であるにもかかわらず、マスター 2 上の RUV が CSN67-2 と大幅に大きくなる場合、問題が発生したと見なされます。これは、マスター 2 からマスター 1 へのレプリケーションが実行されていないことを示します。

障害が発生したため、可能なかぎり多くのデータを保存して、トポロジを再初期化することが必要になった場合は、RUV ピクチャーを使って最新の変更を含むマシンを判別できます。たとえば、前述のレプリケーショントポロジでは、次の RUV を含むハブが存在します。


2: CSN05-2 CSN50-2
1: CSN05-1 CSN43-1

この場合、ハブ 1 は最新の変更を提供する有力な候補と考えられます。

nsds50ruv 属性を使用した 5.x レプリケーションの問題のトラブルシューティング

サーバーが停止すると、nsds50ruv 属性は cn=replica エントリには格納されません。すでに説明したように、これは少なくとも 30 分ごとに、nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, suffix-name エントリに LDAP サブエントリとして格納されます。この情報をファイルにエクスポートするにはこの方法しか存在しないため、この情報は設定ファイルではなくサフィックスに格納されます。トポロジの初期化時にサーバーがオフラインであると、このことが発生します。データは LDIF ファイルにエクスポートされてから、再インポートされます。この属性がエクスポートされたファイルに格納されていない場合、インポート後に新しいレプリカは正しい情報を保持しません。

db2ldif -r コマンドを使用する場合は、常に nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, suffix-name エントリが含まれます。

nsds50ruv および ds6ruv 属性を使用した 6.x レプリケーションの問題の解決

Directory Server Version 6.0 以降では、前の節で説明したように、nsds50ruv 属性を使用してコンシューマの内部状態を表示することもできます。レプリケーション優先順位機能を使用している場合は、ds6ruv 属性を使用できます。この属性には優先順位操作に関する情報が含まれます。レプリケーション優先順位を設定する場合は、レプリケーションルールを作成して特定の変更 (ユーザーパスワードの更新など) が高い優先順位でレプリケートされるように指定できます。たとえば、RUV は次のように表示されます。


nsds50ruv: {replicageneration} 4405697d000000010000
nsds50ruv: {replica 2 ldap://server1:2389}
nsds50ruv: {replica 1 ldap://server1:1390} 440569aa000000010000 44056a23000200010000
ds6ruv: {PRIO 2 ldap://server1:2389}
ds6ruv: {PRIO 1 ldap://server1:1390} 440569b6000100010000 44056a30000800010000

レプリケーション情報を表示するには、次のファイルをエクスポートします。


# dsadm export instance-path suffix-dn [suffix-dn] ldif-file

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

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

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

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


# 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 を特定し、更新履歴ログ内でこのエントリを修復します。

レプリケーション停止またはレプリケーション不一致のトラブルシューティング

この節では、レプリケーション停止およびレプリケーション不一致のトラブルシューティングを行う方法について説明します。次の項目について説明します。

レプリケーション停止の考えられる原因

レプリケーション停止は、次のいずれかが原因で引き起こされることがあります。

レプリケーション不一致の考えられる原因

レプリケーション不一致は、次のいずれかが原因で引き起こされることがあります。

レプリケーション停止またはレプリケーション不一致のデータ収集

この節では、レプリケーション停止またはレプリケーション不一致のトラブルシューティングに役立つ情報の収集方法について説明します。

6.x のエラーログと更新履歴ログの収集

変更を取得していないコンシューマおよびこのコンシューマのサプライヤからエラーログを収集します。デフォルトでは、エラーログは次のディレクトリ内にあります。


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*

5.x のエラーログと更新履歴ログの収集

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 および 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 を使用したレプリケーションの問題のトラブルシューティング」を参照してください。


レプリケーション不一致の原因は、通常は次のいずれかです。



以前のバージョンの Directory Server での分析


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 ツールを使用したレプリケーション停止の診断および修復


上級ユーザーは、replcheck ツールを使って Directory Server 6.x のレプリケーションを確認および修復できます。このツールを使用する際は、Sun サポートのアドバイスに従うことを強くお勧めします。Sun サポートは、このツールで収集した有用な情報を使って、問題を分析したり、さまざまなタイプのレプリケーション停止を直接修復したりできます。このツールは、 install-path/ds6/support_tools/bin/ ディレクトリにあります。


注 – 
以前のバージョンの replcheck ツールは、Directory Server 5.x で使用できます。詳細は、Sun サポートにお問い合わせください。





replcheck コマンドの詳細については、replcheck(1M) を参照してください。



replcheck を使用した問題の診断


診断モードで実行する場合、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 を使用したレプリケーション障害の修復



replcheck diagnose コマンドによってレプリケーション停止が発生していることを確認したら、replcheck fix サブコマンドを使ってレプリケーション停止を修復できます。たとえば、サプライヤが CSN 40 を保持し、コンシューマの保持する CSN 23 は時間が経過しても展開されない場合、このコマンドは CSN 24 に関連するエントリ上でレプリケーションがブロックされたと判断します。


レプリケーション停止を修復するには、次に示すように replcheck fix コマンドを実行します。









replcheck fix TOPOLOGY_FILE






トポロジの再初期化


この節では、トポロジを分析して、再初期化の必要なシステムを判別する方法について説明します。また、レプリケーショントポロジの再初期化に使用可能な方法についても説明します。


注 – 
レプリカを再初期化する場合、すべてのコンシューマレプリカも再初期化する必要があります。




再初期化の対象の特定


トポロジを再初期化するときは、サプライヤからデータの適正なコピーを取得して、トポロジ内のコンシューマ上の不良データを上書きします。トポロジを再初期化する前に、同期されていない、再初期化の必要なシステムを特定してください。この重要な手順を実行することにより、同期済みのデータを上書きして時間を浪費することを防げます。


例として、次の図にハブ 1 でレプリケーションが停止しているトポロジを示します。

レプリケーショントポロジの図
ハブ 1 はデータをコンシューマ A と B に提供していたため、ハブ 1、コンシューマ A、およびコンシューマ B を再初期化する必要があります。


次の例では、コンシューマ A と B はハブ 2 からも更新を受信します。

ハブ 1 と2 がコンシューマ A と B の両方に更新を提供しているレプリケーション配備の図。
コンシューマ A と B は、両方のハブから更新を受信するため、再初期化されたレプリカのサプライヤと同期可能です。そのステータスは、トポロジを再初期化するために選択するレプリカによって変化します。RUV を使用して最新の変更を確実に保持するようにしている場合は、これらのレプリカが最新であるためにコンシューマ A と B を再初期化せずに済む可能性があります。


再初期化の手法の概要


次の手法を使ってトポロジを再初期化できます。



クリーンな再初期化の実行


どの再初期化手法でも不要なデータがコピーされます。たとえば、削除された値または状態情報を保持する値を含むデータや、その他の履歴データなどです。この不要なデータのために、ディスク上のエントリが大きくなります。また、エントリの状態情報の削除が必要になることもあります。レプリケーションの問題の根本原因が、この状態情報に関連している場合は、データが引き続きデータベース内に存在しているため、別のレプリケーションエラーの原因になる可能性があります。この不要で疑わしいデータをインポートすることを避けるために、トポロジのクリーンな再初期化を実行できます。


クリーンな再初期化を実行する際、より小さいデータベース、インデックス、および空の更新履歴ログを含むデータのクリーンなマスターコピーを作成します。クリーンな再初期化では、データベースファイルのバックアップコピーを作成しないため、ディスクスペースの消費が少なく、処理に要する時間も少なくなります。さらに、パフォーマンス低下の原因になり得るインデックスの断片化も減少します。ただし、データベースファイルを一貫した状態に保つため、クローン作成の対象となるサーバーを停止する必要があります。



ProcedureDirectory Server Version 6.3 でクリーンなマスターデータを作成する


    


  1. 

    マスターサーバーを停止します。
    


    2. 


  2. 

    
dsadm コマンドを使用して、データベースの内容をエクスポートします。
    


    
-Q オプションを使用して、レプリケーション情報をエクスポートから除外します。
    


    

    


    

    # dsadm export -Q instance-path suffix-DN  /tmp/clean-export.ldif
    
    		

    

    

    3. 


  3. 

    
dsadm コマンドを使用して、エクスポートしたデータを同じマスターサーバーに再インポートします。
    


    

    


    

    # dsadm import instance-path /tmp/clean-export.ldif suffix-DN

    
    		

    

    

    4. 


  4. 

    マスターサーバーを再起動します。
    


    これで、マスターサーバーに含まれるデータはクリーンになりました。つまり、より小さいデータベース、インデックス、および空の更新履歴ログがマスターサーバーに含まれています。
    


    5. 


  5. 

    クリーンなマスターデータを、システム内のほかのすべてのサーバーにインポートします。
    


    
「再初期化の手法の概要」で説明した 3 つの手法のいずれかを使用します。
    


    6. 




ProcedureDirectory Server Version 5.x でクリーンなデータを作成する


    


  1. 

    マスターサーバーを停止します。
    


    2. 


  2. 

    
db2ldif スクリプトを -r オプションを指定せずに実行して、データベースの内容をエクスポートします。
    


    

    


    

    # db2ldif -n database1 -a /tmp/clean-export.ldif
    
    		

    

    

    3. 


  3. 

    
ldif2db スクリプトを使用して、エクスポートしたデータを同じマスターサーバーに再インポートします。
    


    

    


    

    # ldif2db -n database1 -i /tmp/clean-export.ldif
    
    		

    

    

    4. 


  4. 

    マスターサーバーを再起動します。
    


    これで、マスターサーバーに含まれるデータはクリーンになりました。つまり、より小さいデータベース、インデックス、および空の更新履歴ログがマスターサーバーに含まれています。
    


    5. 


  5. 

    クリーンなマスターデータを、システム内のほかのすべてのサーバーにインポートします。
    


    
「再初期化の手法の概要」で説明した 3 つの手法のいずれかを使用します。
    


    6. 




ProcedureDSCC を使用してサフィックスを再初期化する


この手法には、サプライヤとコンシューマサフィックス間のレプリケーションアグリーメントが必要です。この手法を使用して、1 つのサフィックスを再初期化するか、または小さいサフィックスを多数再初期化します。


注 – 
以前のバージョンの Directory Server コンソールを使用している場合は、「設定」パネルを表示して「レプリケーション」ノードを選択します。コンシューマ内で初期化するサフィックスを選択します。コンシューマに対するレプリケーションアグリーメントを選択します。アグリーメントを選択して、コンシューマをすぐに初期化します。





    


  1. 

    サプライヤサーバーで、DSCC にログインします。
    


    2. 


  2. 

    「ディレクトリサーバー」タブをクリックしてから、「サフィックス」タブをクリックします。
    


    3. 


  3. 

    「サフィックス」タブで、再初期化の必要なサフィックスを 1 つ以上選択します。
    


    ドロップダウンメニューから「データを用いたサフィックスの初期化」を選択します。
    


    4. 


  4. 

    「手順 1」で、「既存のレプリケーションアグリーメントを使用して初期化する」を選択します。
    


    5. 


  5. 

    「手順 2」で、データのコピー元のサプライヤサフィックスを指定します。
    


    6. 


  6. 

    コンシューマのエラーログをチェックして、インポートが完了したことを確認します。
    


    7.