レプリケーション停止データの分析

収集したデータを使って、レプリケーション停止の原因がサプライヤまたはコンシューマの問題であるかどうかを判別します。

収集した 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 ファイルで置き換えます。