破損通知は、削除、移動、名前変更、復元などの操作中に、eDirectoryが参照整合性を保持するためにオブジェクトに付加する操作属性です。たとえば、グループAにユーザBというメンバーが含まれているとき、ユーザBが削除されると、ディレクトリは自動的にグループAからユーザBへの参照を削除します。eDirectory 9.0では、削除、移動、および名前変更の操作によって生成される破損通知が、デフォルトで最適化されます。
メモ:破損通知を含むオブジェクトは、エージェントのアウトバウンド同期の実行時、およびインバウンド同期サイクルの最後に実行されるようにスケジュールされている破損通知処理の実行時に調査の対象となります。
破損通知には大きく分類して3つの種類があります。
プライマリ破損通知には、停止(0001)、復元(0000)、移動(0002)、新規RDN(0005)、およびツリーの新規RDN(0008)の各種類がありあます。
セカンダリ破損通知は、一般的にプライマリ破損通知に関連付けられており、プライマリ破損通知で指定された操作の通知が必要なエージェントおよびパーティションを表します。セカンダリ破損通知には、バックリンク(0006)、使用中(000C)、およびツリーの移動(000a)の各種類があります。
トラッキング破損通知には移動禁止(0003)、古いRDN(0004)、およびツリーの古いRDN(0007)の各種類があります。
トラッキング破損通知以外の破損通知は、次の同期ステータスのセットを使用して移動する必要があります。
初期化ステータスまたは発行済み(0)
通知済み(1)
パージ準備完了(2)
パージ可能(4)
ステータスは破損通知属性のフラグフィールドで記録されます。破損通知が次のステータスに進む前に、現在のステータスは必ず実オブジェクトのすべてのレプリカに同期されます。リング内のすべてのレプリカが破損通知ステータスを与えられているかどうかを判断するために、遷移ベクトルからベクトルが計算されます。eDirectory 8.6以降では、保存されていない破損通知ベクトルが使用されます。以前のバージョンのeDirectoryでは、パージベクトルが使用されます。破損通知の変更タイムスタンプ(MTS)が計測ベクトルよりも古い場合、担当サーバは該当する破損通知を次のステータスに進めることができます。
「バックリンク」のセカンダリ破損通知の場合、該当する破損通知を含むオブジェクトのマスタレプリカを持つエージェントがステータスを進めます。「使用中」のセカンダリ破損通知の場合、レプリカが存在している間は該当する破損通知を作成したエージェントがステータスを進めます。レプリカが存在しない場合、パーティションのマスタを保持しているエージェントが「使用中」の破損通知のステータスを進めます。「ツリーの移動」の破損通知の場合、ルートパーティションのマスタがステータスを進めます。
プライマリ破損通知は、すべてのセカンダリ破損通知が最後のステータスまで進められた後でのみ、ステータスを進めることができます。プライマリ破損通知が最後のステータスまで進んだ後で、そのステータスがリング内のすべてのサーバに同期されると、残っているのは属性を持たないオブジェクトであるオブジェクトハスクのみとなり、これらはシステムのパージプロセスによってパージされます。トラッキング破損通知は、プライマリ破損通知の削除の準備が完了した後か、Inhibit_moveの場合はプライマリ破損通知がマスタレプリカのOBF_NOTIFIEDステータスに移動された後で削除されます。
破損通知の処理を担当するレプリカは、指定したパーティションがインバウンド同期サイクルを終了した後で、パーティションごとにスケジュールされているバックグラウンド処理(破損通知処理)を実行します。パーティションにその他のレプリカがない場合、アウトバウンドレプリケーション処理がハートビート間隔でスケジュールされたままになります。その後、アウトバウンドレプリケーション処理によって破損通知処理が開始されます。破損通知処理は手動ではスケジュールできず、また、その必要もありません。同期化が実行されると、遷移ベクトルが更新され、パージベクトルおよびObitベクトルを進めます。これらのベクトルが進められると、破損通知のステータスを進めることができます。これと同時に、インバウンド同期に自動スケジュールが実行されると、破損通知処理サイクルが完了します。すなわち、破損通知処理の起動要因はオブジェクト同期です。
削除されたオブジェクトの場合、「停止」のプライマリ破損通知に関連するすべての破損通知が最後のステータス(パージ可能)まで進められ、そのステータスがすべてのレプリカに同期された後で、新しい処理がデータベースに残っているエントリハスクの削除を担当します。これらのハスクを削除するために、パージ処理が自動的に実行されます。パージ処理は、手動でスケジュールでき、エージェントアクティビティの表示で説明しているように、その自動スケジュール間隔を変更することもできます。
破損通知オブジェクトを表示した状態で、リング周辺の破損通知を比較しながらレプリカリングを調べます。
破損通知のコピーがないレプリカがあり、すべての属性値がパージ可能ではない場合、このオブジェクトはレプリカリング周辺で矛盾しており、破損通知が孤立していると考えられます。
オブジェクトがすべてのレプリカに矛盾なく存在している場合、同期エラー、または破損通知処理にエラーが発生しているために次のステータスに進まない可能性があります。
この問題を回避するには次の手順に従ってください。
推奨される方法: レプリカリング内のサーバのいずれかにeDirectory 8.6以降のバージョンを使用する場合、iMonitorのオブジェクトを参照し、［Send Single Entry］を選択します。これにより、その他のすべてのレプリカに信頼されていない送信が実行されます。
避けるべき方法: 孤立した破損通知のコピーを持つレプリカリングにあるすべてのサーバがeDirectory 8.6よりも前のバージョンの場合、DSBrowseを-aオプションでロードして、オブジェクトを参照し、エントリにタイムスタンプを設定します。これにより、このサーバに存在するオブジェクトを信頼されたコピーとして指定します。Novellでは、実際にはオブジェクトを信頼されたオブジェクトとして指定することはお勧めしません。
オブジェクトの破損通知がこのサーバに保存されていない(該当するオブジェクトが外部参照の)場合、次を実行します。
一致する破損通知が実オブジェクトに含まれているかどうかをチェックします。一致する破損通知が含まれていない場合、この破損通知は孤立しています。
一致する破損通知が実オブジェクトに含まれている場合、実オブジェクトの破損通知の問題を解決してから、ExtRefパーティションにある破損通知の問題を処理してください。
この問題を回避するには次の手順に従ってください。
推奨されない方法: タイムスタンプオプションが選択されているDSRepairを実行します。
推奨されない方法: 実レプリカをサーバに移動し、使用可能な状態になってから破損通知が処理されるのを待ちます。破損通知が処理されたら、レプリカは削除してもかまいません。
破損通知が正確に同期するようにするには、次のことを実行してください。
iMonitorのエージェント同期のページを使用して同期エラーをチェックおよび解決してください。
破損通知は、レプリカリングのコピーを保持するすべてのエージェントがステータスの変更を確認した後でのみステータスを変更できます。すべてのレプリカがデータを認識したことを確認するには、次のようないくつかの方法があります。
破損通知を含むエントリを参照しながら、エントリ同期リンクをクリックします。すべてのレプリカに同期されていない属性がすべて表示されます。
破損通知属性値の中で、最も古いタイムスタンプを検索します。検索されたタイムスタンプの時刻と現在時刻の差が、パーティション同期ページの最大リングデルタフィールドの間隔よりも大きい必要があります。
遷移ベクトルを調査します。
エラーを検索するには、エージェントプロセスのステータス: 破損通知を検査してください。
エージェントプロセスステータス: 破損通知で起こりうる一般的な問題には、次のものがあります。
-625、-622、-634、および-635の通信エラー。詳細については、サーバ情報レポートを参照してください。
-601および-603は、適切に削除されていないサーバ、またはサーバオブジェクトに不明なベースクラスが含まれるサーバを示します。
このページに表示されるエラーは致命的なものではありません。そのパーティションで破損通知処理が次回実行されるときに、この操作が再試行されます。このページに表示された問題を解決して、再試行まで待機してください。
過去には、停止した破損通知を解決するためにいくつかの異なる手段をとりました。これらの手段の一部は、費用のかかるパーティション操作、または将来的に問題の原因となる可能性のあるドキュメント化されていない機能の使用に関連しています。
1つ目に使用されていたのは、マスタを保持しているレプリカを切り替える方法です。マスタはさまざまなステータスを通じてバックリンクの破損通知の移動を担当しているエージェントなので、この手段が有効な場合もあります。レプリカに矛盾がありマスタが削除されたオブジェクトを保持していない場合、該当するマスタを、破損通知と一緒に削除されたエントリを保持していたエージェントに切り替えると、新規エージェントに破損通知のステータスを次に進めてパージすることのできるライセンスが与えられます。［Send Single Entry］を選択すると、より確実で危険性の低い方法で、レプリカの矛盾が原因で停止している破損通知の問題を解決します。
2つ目に使用されていたのは、DSRepairを実行してすべての破損通知を削除するスイッチを使用する方法です。(DSRepairを起動して、停止している破損通知を解決するサードパーティ製のアプリケーションがあります。)この方法はお勧めできません。これらのスイッチを使用すると、このエージェントにあるすべての破損通知が削除されます。したがって停止していない破損通知も削除される可能性があり、レプリカの矛盾性がさらに深まり、より多くの停止している破損通知が作成される場合があります。これは分散された操作ではないので、停止している破損通知のあるすべてのサーバでDSRepairを実行する必要があります。この操作は、これらのサーバの1つで処理未了のまま削除されてしまうパーティションの破損通知を取得する可能性を高めます。処理未了のまま破損通知を削除すると、孤立した破損通知を新たに生み出す可能性があり、その結果として数年後にレプリカタイプの変更、新規レプリカの追加、またはその他のパーティション操作を実行したときに問題が生じる場合があります。
3つ目に使用されていたのは、カスタムモード操作でDSBrowseを使用してエントリにタイムスタンプを設定するか、またはRSRepairで-0Tスイッチを使用してオブジェクトを信頼されたオブジェクトに指定する方法です。この操作によりエントリは信頼されたエントリに指定され、他のすべてのレプリカにこのエントリを同期します。その他のサーバで変更されたデータを失う可能性があるので、この操作の実行には細心の注意を払う必要があります。破損通知のクリーンアップの方法としては、なるべく使用しないことをお勧めします。