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

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

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

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

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

• insync および repldisc コマンドを使用して得た、トポロジ規模のデータ。

• マスター 1 と 2、およびコンシューマ 4 の RUV を使用して得た、ブロックしている CSN に関する情報。

• 問題に関与している可能性のある各参加者の情報。ブロックしている CSN が作成された日付に関係する dse.ldif、nsslapd -V、access ログと errors ログ (レプリケーションを有効に設定) を含む。

• 正しく機能しており、問題に関与していないと思われるレプリケーション参加者の情報。dse.ldif、nsslapd -V、および access ログと errors ログ (レプリケーションを有効に設定) を含む。

このデータを使って、遅延の始まりを特定できます。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 からデータを収集します。稼働中のサーバーから得たデータを比較し、問題が発生した時点に注目することで、相違点を識別できます。たとえば、ハブが別のマスターまたはサブネットからレプリケートされていたり、レプリケーションの問題が発生した変更の直前に別の変更がハブに含まれていたりすることがあります。