| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド 11g リリース 1 (11.1.1.7.0) B72443-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド 11g リリース 1 (11.1.1.7.0) B72443-01 |
|
前 |
次 |
この章では、レプリケーションに関する問題のトラブルシューティングに役立つ情報について説明します。また、トポロジ全体の再初期化に役立つ手順についても説明します。この章の内容は次のとおりです。
この項では、レプリケーションに関する問題の一般的な分析手順を紹介します。レプリケーションの動作およびレプリケーション・データの収集に使用可能なツールについて説明します。
レプリケーション・エラーが発生した場合、レプリケーション・トポロジから最小限のデータを収集する必要があります。
アクセス・ログ、エラー・ログおよび監査ログ(使用可能な場合)から情報を収集する必要があります。エラー・ログを収集する前に、レプリケーション情報を保持するためにログ・レベルを調整します。レプリケーションが含まれるようにエラー・ログ・レベルを設定するには、次のコマンドを使用します。
# dsconf set-log-prop ERROR level:err-replication
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」を参照してください。
repldiscコマンドの使用方法repldiscコマンドでは、RUVを使用して既知のレプリカすべてのグラフを作成して、レプリケーション・トポロジを表示します。次に、トポロジを表す隣接行列を出力します。このコマンドの出力にはマシン名とその接続が表示されるため、それを使用してinsyncツールの出力を読み取ることが容易になります。Directory Serverの6.0以上のバージョンでは、このコマンドを次のように実行します。
# 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 | |
---+---------------
この例では、2つのマスターが3つのハブにレプリケートされ、そこから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のCSN35に関連付けられている変更の次の変更に関係している可能性があります。CSN35に関連付けられている変更は、これまでコンシューマ4にレプリケートされた最も古いCSNに対応しています。CSN35-01のレプリカのアクセス・ログでgrepコマンドを使用して、問題が発生した時間を特定できます。トラブルシューティングは、この特定の時点から開始する必要があります。
「問題の範囲の定義」で説明したとおり、問題の発生時点の特定に役立つ情報を動作中のシステムから入手することが有効です。そのため、期待どおりに機能しているハブ1およびコンシューマ1からデータを収集します。機能しているサーバーのデータと比較し、問題が始まった時点に注目することで、相違点を識別できます。たとえば、ハブが別のマスターまたは別のサブネットからレプリケートされていたり、レプリケーションの問題が発生した変更の直前に別の変更が含まれている場合があります。
問題の症状に応じて、トラブルシューティング方法は異なります。
たとえば、コンシューマのアクセス・ログに何も表示されない場合は、ネットワークの問題がレプリケーションのエラーの原因となることがあります。再初期化は必要ありません。
変更ログに特定のエントリが見つからないことがエラー・ログに示される場合は、マスターの変更ログが最新ではありません。トポロジの再初期化が必要かどうかは、最新の変更ログがレプリケーション・トポロジ内(ハブや他のマスターなど)にあるかどうかによります。
処理ループやロックの中断など、コンシューマに問題がある場合は、アクセス・ログを参照して、特定のCSNで多数実行されている再試行を見つけます。replckツールを実行してレプリケーション停止の原因となったCSNを特定し、変更ログ内でこのエントリを修復します。
この項では、レプリケーション停止およびレプリケーション相違のトラブルシューティング方法について説明します。含まれる内容は、次のとおりです。
レプリケーション停止は、次のいずれかによって発生する可能性があります。
レプリケーション承諾が無効である
サプライヤの変更ログに変更レコードが欠落している
サプライヤの変更ログのキャッシュが破損している
レプリケーション・マネージャーが無効な資格証明を使用している
スキーマが競合している
Update Resolution Protocol (URP)の競合によって操作がコンシューマ上で許可されていない
ネットワークが切断されている
使用できないサプライヤによってコンシューマの状態がロックダウンされている
コンシューマのディスクが不足している
レプリケーション相違は、次のいずれかによって発生する可能性があります。
コンシューマの性能がサプライヤより劣る
コンシューマのディスクが読取り/書込み制限の上限に達している
断続的なネットワークおよびパケット削除の問題がある
変更ログのメモリー内キャッシュが使用されていない
この項では、レプリケーション停止およびレプリケーション相違のトラブルシューティングに役立つ情報の収集方法について説明します。
変更を取得していないコンシューマおよびこのコンシューマのサプライヤからエラー・ログを収集します。デフォルトでは、エラー・ログは次のディレクトリにあります。
instance-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
insyncおよびrepldiscコマンドを使用したデータの収集insyncおよびrepldiscコマンドの出力を使用して、レプリケーション相違のトラブルシューティングに役立てます。
insyncコマンドは、マスター・レプリカと1つ以上のコンシューマ・レプリカ間の同期状態を示し、ボトルネックの特定に役立てることができます。レプリケーション相違の問題をトラブルシューティングする場合、このデータが定期的である必要があります。詳細は、「insyncコマンドの使用方法」を参照してください。
insyncコマンドを使用してボトルネックを特定する場合、たとえば、ボトルネックが遅延の増加によるものであるとツールによって報告された場合、nsds50ruvおよびds6ruv属性のデータを収集を開始することは有効です。このデータは、停止の可能性の発生時間および場所の特定に役立ちます。Replica Update Vectors (RUV)の詳細は、『Oracle Directory Server Enterprise Editionリファレンス』のReplica Update Vectorに関する説明を参照してください。
repldiscコマンドでは、既知のレプリカすべてのグラフを作成して、レプリケーション・トポロジを表示し、結果をマトリックスで示します。詳細は、「repldiscコマンドの使用方法」を参照してください。
コンシューマとサプライヤの両方で次のようにnetstatコマンドを使用して、レプリケーション停止がネットワークに関連しているかどうかの判別を試みます。
# netstat -an | grep port
アクセス・ログにはサプライヤが更新を送信していることが示されているにもかかわらず、コンシューマが情報を受信しない場合は、ネットワークがレプリケーション停止の原因である可能性があります。pingおよびtracerouteコマンドを実行しても、ネットワーク待機時間が問題の原因であるかどうかを判別するのに役立ちます。
スワップ情報を収集して、メモリーが不足しているかどうかを確認します。スワップ・コマンドの出力が小さい場合は、メモリーが問題の可能性があります。
| プラットフォーム | スワップ情報収集の意味 |
|---|---|
|
Solaris |
|
|
HP-UX |
|
|
Linux |
|
|
Windows |
|
ディスク・コントローラが完全にロードされているか、入出力がレプリケーションの問題の原因かどうかの判別を試みます。ディスク関連の問題かどうかを判別するには、次のようにiostatツールを使用します。
# iostat -xnMCz -T d 10
iostatコマンドは、端末、ディスクおよびテープ入出力アクティビティを反復的にレポートし、レプリケーション相違イベントが、コンシューマ側の飽和したディスクが原因かどうかの判別に役立てることができます。
収集したデータを使用して、レプリケーション停止の原因がサプライヤまたはコンシューマの問題であるかどうかを判別します。
収集したnsds50ruv属性の出力を使用して、特定のコンシューマにレプリケートされた最後のCSNを特定します。次に、コンシューマのアクセス・ログおよびエラー・ログ(レプリケーション・レベルの出力を収集するように設定されたログ)を使用して、レプリケートされた最後のCSNを特定します。このCSNから、レプリケーション・プロセスが提供に失敗する次のCSNを特定できます。たとえば、レプリケーションが失敗する場合、サプライヤがCSNをレプリケートしない、ネットワークがCSNをブロックしている、コンシューマが更新の受入れを拒否しているなどが原因となっている可能性があります。
コンシューマ上でCSNを更新できない可能性があります。サプライヤが更新できないCSNのgrepをコンシューマ上で次のように試みます。
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/resources/schemaディレクトリの内容を使用します。次のように、ディレクトリを1つのファイルとして保存します。
# tar -cvs schema schema.tar
FTPを使用して、このtarファイルをトポロジ内のその他すべてのサプライヤおよびコンシューマにエクスポートします。各サーバーの/install-path/resources/schemaディレクトリを削除して、マスター・スキーマ参照で作成したtarファイルで置き換えます。
iostatツールの出力を使用して、レプリケーション相違がコンシューマ上のディスクパフォーマンスの低下が原因かどうかの判別を試みます。ディスク・パフォーマンスの問題の診断の詳細は、「例: RUVおよびCSNを使用したレプリケーションに関する問題のトラブルシューティング」を参照してください。
通常、レプリケーション相違の原因は、次のいずれかです。
ネットワークの容量が不十分で、更新の生成速度に対応した転送速度を保証できません。非常に狭い帯域幅で操作している場合、ネットワークの容量が問題になる場合があります。
コンシューマの速度が受信する変更を適用するには十分ではありません。たとえば、ディスク使用量が飽和状態にあるか、レプリケーションがパラレルに実行されたとき(索引が指定されていない検索など)に問題が発生する場合は、コンシューマの速度が問題になることがあります。
replcheckツールを使用したレプリケーション停止の診断および修復上級ユーザーはreplcheckツールを使用して、Directory Serverのレプリケーションを確認および修復できます。このツールは、Sunのサポートの指示に従って使用することを強くお薦めします。このツールは、Sunのサポートが問題の診断時に使用可能な有用な情報を収集し、様々な種類のレプリケーション停止を直接修復できます。このツールは、install-path/bin/support_tools/ディレクトリにあります。
replcheckコマンドの詳細は、「replcheck」を参照してください。
replcheckを使用した問題の診断診断モードで実行すると、replcheckツールは、レプリケーション破損の原因を診断し、推奨する修復アクションの概要を示します。レプリケーション・トポロジ内の各サーバーのRUVを比較して、マスターが同期しているかどうかを確認します。検索結果が、すべてのコンシューマ・レプリカのメモリー内RUVが定時に展開されるか、展開されないがサプライヤ・レプリカのRUVと等しいことを示す場合、このツールはレプリケーション停止が発生していないと判断します。
レプリケーションの問題を診断するには、次のようにreplcheckツールを実行します。
replcheck diagnose topology-file
topology-fileには、hostname:port:suffix_dn[:label]の書式でファイルへのパスを指定し、各行に1つのレコードを含めます。オプションの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サブコマンドを起動してこのレプリケーション停止を修復できます。たとえば、サプライヤがCSN40を保持し、コンシューマが保持するCSN23が時間が経過しても展開されない場合、このコマンドはCSN24に関連付けられているエントリでレプリケーションがブロックされたと判断します。
レプリケーション停止を修復するには、次のようにreplcheck fixコマンドを実行します。
replcheck fixTOPOLOGY_FILE
次の各項を参照して、nsds50ruvおよびds6ruv属性を使用してレプリケーションをトラブルシューティングします。
nsds50ruv属性の使用方法サーバーが停止した場合、nsds50ruv属性はcn=replicaエントリに格納されません。少なくとも30秒ごとに、DNがnsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,suffix-nameであるLDAPサブエントリとしてデータベースに格納されます。これがこの情報をファイルにエクスポートする唯一の方法であるため、この情報は構成ファイルではなくサフィックスに格納されます。トポロジを初期化する場合、サーバーがオフラインのときにこれが発生します。データはLDIFファイルにエクスポートされ、その後再インポートされます。この属性がエクスポートされたファイルに格納されていなかった場合、インポート後の新しいレプリカには正しい情報が含まれません。
db2ldif -rコマンドを使用する場合、常に、nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,suffix-nameエントリが含まれます。
nsds50ruvおよびds6ruv属性の使用方法Directory Serverの6.0以上のバージョンでは、前述の項で説明したとおり、nsds50ruv属性を使用してコンシューマの内部状態を確認することもできます。レプリケーション優先度機能を使用している場合は、優先度操作に関する情報が含まれているds6ruv属性を使用できます。レプリケーション優先度が構成されている場合は、ユーザー・パスワードの更新などの特定の変更を高い優先順位でレプリケートするように指定するレプリケーション・ルールを作成できますが、たとえばRUVは次のように表示されます。
# ldapsearch -h host1 -p 1389 -D "cn=Directory Manager" -w secret \
-b "cn=replica"
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
この項では、再初期化が必要なシステムを特定するためにトポロジを分析する方法について説明します。レプリケーション・トポロジを再初期化するために使用できる方法についても説明します。
|
注意: レプリカを再初期化する場合は、すべてのコンシューマ・レプリカも再初期化する必要があります。 |
トポロジを再初期化する場合は、サプライヤからデータの適切なコピーを取得して、トポロジ内のコンシューマ上の不良データを上書きします。トポロジを再初期化する前に、同期化されていない、再初期化が必要なシステムを特定します。この重要な手順によって、すでに同期化されているデータを上書きすることで時間を無駄にすることを防げます。
たとえば、次の図は、ハブ1でレプリケーションが破損しているトポロジを示します。
ハブ1はコンシューマAおよびBにデータを提供していたため、ハブ1、コンシューマAおよびコンシューマBを再初期化する必要があります。
次の例では、コンシューマAおよびBは、ハブ2からも更新を受信します。
コンシューマAおよびBは、両方のハブから更新を受信するため、再初期化したレプリカのサプライヤと同期できます。これらのステータスは、トポロジを再初期化するために選択したレプリカによって異なります。最新の変更を確実に保持するためにRUVを使用する場合は、これらのレプリカは最新のため、コンシューマAおよびBを再初期化する必要がない場合があります。
すべての再初期化方式で不用なデータ(削除された値を含むデータや状態情報やその他の履歴データを保持するデータなど)がコピーされます。この不要なデータによって、ディスク内のエントリが大きくなります。また、エントリの状態情報も消去する必要がある場合があります。レプリケーションの問題の根本原因がこの状態情報に関連している場合、データがまだデータベースに存在するため、別のレプリケーション・エラーの原因となる可能性があります。この不要で問題となる可能性のあるデータのインポートを防ぐために、トポロジのクリーンな再初期化を実行できます。
クリーンな再初期化を実行する場合は、小規模なデータベース、索引および空の変更ログを含むデータのクリーンなマスター・コピーを作成します。クリーンな再初期化では、データベース・ファイルのバックアップ・コピーを作成しないため、少ないディスク領域ですみ、時間もかかりません。さらに、パフォーマンス低下の原因になり得る索引断片化も減少します。ただし、データベース・ファイルの整合状態を保証するために、クローニング中のサーバーを停止させる必要があります。
マスター・サーバーを停止します。
dsadmコマンドを使用して、データベースの内容をエクスポートします。
レプリケーション情報がエクスポートに含まれないように、-Qオプションを指定します。
# dsadm export -Q instance-path suffix-DN /tmp/clean-export.ldif
dsadmコマンドを使用して、エクスポートしたデータを同じマスター・サーバーに再インポートします。
# dsadm import instance-path /tmp/clean-export.ldif suffix-DN
マスター・サーバーを再起動します。
これで、マスター・サーバーにはクリーンなデータ(小規模なデータベース、索引および空の変更ログ)が含まれています。
クリーンなマスター・データをシステム内のその他すべてのサーバーにインポートします。
この方法には、サプライヤとコンシューマのサフィックス間のレプリケーション承諾が必要です。この方法を使用して、1つのサフィックスを再初期化するか、または多数の小さいサフィックスを再初期化します。
|
注意: Directory Serverコンソールの以前のバージョンを使用している場合は、「構成」パネルに移動して「レプリケーション」ノードを選択します。コンシューマ内で初期化するサフィックスを選択します。コンシューマに対するレプリケーション承諾を選択します。承諾を右クリックして、「コンシューマをすぐに初期化」を選択します。 |
サプライヤのサーバー上で、DSCCにログインします。
「ディレクトリ・サーバー」タブをクリックして、次の「サフィックス」タブをクリックします。
「サフィックス」タブで、再初期化する必要があるサフィックスを選択します。
ドロップダウン・メニューから、「データからサフィックスの初期化」を選択します。
手順1で、「既存のレプリケーション承諾を使用して初期化」を選択します。
手順2で、データのコピー元のサプライヤのサフィックスを指定します。
コンシューマのエラー・ログを確認して、インポートが完了したことを確認します。
