現象

ログファイルに次のメッセージの1つが表示されます。
WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId -
        Unknown parent node with id ...ERROR ... failed to read bundle: ...

原因

これらの問題には複数の原因があります。考えられる原因 (CRX のバージョンによって) :

最も一般的な原因は、同じセッションを使用して同時変更を行うことです。この場合、CRX error.log ファイルには少なくとも 1 つの ConcurrentModificationException が含まれています。

分析、解決策

この現象は、インデックス(およびワークスペースも可能)で一貫性がないことを示しています。

通常、不整合の影響は低くなります。問題の原因は、ログファイルにエラーが発生してエラーが発生したことです。

不整合タイプ

  • Orphaned 子
    • エラーメッセージ:NodeState CHILD_ UUID は存在しない parent ポンド PARENT_ UUID を参照する
    • 一貫性チェックメッセージ:ConsistencyCheck:修正できます。ノード
      CHILD_ UUID か。不明な親を持ちます。
      PARENT_ UUID か。(ConsistencyCheck.java の116行目)
    • 現在のソリューション:CRX コンソールを使用します(記事を見る)
  • 親参照 inexistent 子
  • 子参照無効な親
    • エラーメッセージ : ChildNode に無効な親 quid があります : INVALID_PARENT_UUID (VALID_PARENT_UUID ではなく)
    • 現在のソリューション:CRX コンソールを使用します(記事を参照してください)
  • 既存の子が参照されていない
  • ノードが存在します
  • 不一致なインデックスを検索してください
    • エラーメッセージ:WARN NodeIteratorImpl: Exception retrieving Node with UUID: 003171fe-e2e8-457b-a3af-f74eed12c1b9: javax.jcr.ItemNotFoundException: 003171fe-e2e8-457b-a3af-f74eed12c1b9
    • 現在のソリューション:検索用インデックスの再作成あるいは不一致インデックスの検索確認および修正を稼動
  • 不整合の検索
    • エラーメッセージ:「org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getNode」がスタックトレース内で見られる場所にある「javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496が原因」
    • 現在のソリューション:以下を確認 adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix"> インデックス不一致確認の検索と修正
  • バージョン関連の不一致
    • org.apache.jackrabbit.core.version.InternalXAVersionManager コードに関連するエラーメッセージスタックが表示されます。
    • 現在のソリューション:この記事を確認する
  • ファイルが見つかりません
    • エラーメッセージ:ERROR TarPersistenceManager: Failed to read bundle: [quid]: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
      java.io.IOException: File not found: nnnnn
    • 現在の解決策:ファイルがバックアップ(data_nnnnn.tar)にあるかどうかを確認するか、再起動時に index_*.tar を削除して再起動します。

検索用インデックスの修正

検索用インデックスの不整合は、次のような場合に発生する可能性があります:

  • 書き込み操作中の java プロセスのあんクリーンシャットダウン。これは、Linux または UNIX の-9 キルおよび Windows OS のタスクマネージャーのプロセスキルであるようです。
  • 最新の CQ と CRX ホットフィックスで修正された CRX 古いバグ(CRX2.2、2.3および2.4の場合)。これらを回避するには、CRX ホットフィックスの最新情報を常に最新の状態に保つ必要があります。  最新のホットフィックスであると思われる場合、アドビのサポートにサポートチケットを提出してください

検索インデックスの不一致を修正する方法は2つあります。

  • 検索インデックスの一貫性のチェックおよび修正
  • 検索インデックスを再作成する

Search Index Consistency Check and Fix

起動時にインデックスの一貫性チェックを実行できます。the workspace.xml 内に <SearchIndex class="...">エレメントの中に2つのパラメーターを追加:

<param name="enableConsistencyCheck" value="true"/>
<param name="forceConsistencyCheck" value="true"/>

3 番目のパラメーターでは、エラーを修復するか、またはログのみを記録するかを制御します:

<param name="autoRepair" value="false"/> <!-- default is true -->

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
    <param name="path" value="${wsp.home}/index"/>
    <param name="enableConsistencyCheck" value="true"/>
    <param name="forceConsistencyCheck" value="true"/>
    <param name="autoRepair" value="true"/>
</SearchIndex>

Search Index の再作成

検索インデックスを再作成すると、検索インデックスの不一致がすべて修正されます。ただし、検索インデックスの一貫性をチェックして修正するよりも大幅に時間がかかります。  このため、検索インデックスの再構築を計画するときに特別な注意が必要です。また、多くのダウンタイムを考慮して、代わりにチェックや修正を行うことを検討してください。

インデックス再構築の計画

インデックスを再構築するために必要な時間は、複数の異なる要因(ノードの総数、アセットファイル、アセットファイルの種類など)によって異なります。このため、まず、非運用環境で再構築をテストする必要があります。非運用テストを使用して、実稼働環境に必要な停止ウィンドウの長さを計算します。2-10GB サイズの小さいリポジトリを30分~6時間かかることがあり、より大きなリポジトリは6時間~2日間もかかる場合があります。

インデックスを再構築する方法

検索インデックスを再構築するには、次の操作を行います。

  1. CRX(または CQ)を停止
  2. バックアップおよびリポジトリの次のディレクトリを削除します:crx-quickstart/repository/workspaces/crx.default/index/ and crx-quickstart/repository/repository/index/
  3. CRX(または CQ)を起動すると、再構築が開始されます。  進行状況を表示するため、CRX2.2 で logs/crx/error.log を、CRX2.3では logs/error.log をモニターします。  CRX インスタンスにアクセスできる場合は、インデックスが作成されたことを伝えることができます

作業領域持続マネージャーの一貫性チェックと修正

これで問題が解決せず、修復できないエラーが出力された場合は、作業領域のデータに矛盾が生じる可能性があります。

持続マネージャーはリポジトリの整合性をチェックして、起動時の問題を解決することができます。一貫性チェックを有効にして、自動的に問題を解決するには、各<PersistenceManager class="...">要素の中の repository.xml 及び workspace.xml に次のパラメータを追加し、CRX を再起動します。

デフォルトの CQ5.2.x のインストールで、これらのファイルは crx-quickstart/repository/workspaces/*/workspace.xml and crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml の下にあります。

CQ5.3では、代わりに repository.xml が crx-quickstart/repository/repository.xml にあります。

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

次の起動時に、チェック/修復(インデックスまたは永続マネージャ)のどちらかが実行されます。整合性チェックが終了したら、関連する設定を無効にします。そうしないと、CRX の起動時に常に consistency チェックを実行します。

整合性チェックのみが有効な場合は、inconsistentBundleIds.txt がワークスペースディレクトリに作成されます。

整合性フィックスのみが有効になっている場合、ファイル inconsistentBundleIds.txt は読み取られ、これらのノードは修正されます。すべてのファイルが修正可能な場合、ファイルは削除されます。

クラスター内の不整合の修正

クラスター環境で整合性修正を実行する場合、1つのクラスターノードでのみ実行します。整合性修正を実行している時には、他のクラスターノードを起動しないでください。終了後、他のクラスターノードを開始できます。

不整合の迅速な修正

整合性チェックでは、すべてのノードがスキャンされますので、速度が低下します。メンテナンス時間を短縮するには、リポジトリのコピーの整合性チェックを実行し、破損しているノードだけを修正します。これを行うには、次の手順に従います。

  • オンラインバックアップ機能を使用してリポジトリをコピーする
  • 整合性チェックを実行し、リポジトリのコピーを別のマシン上などで修正します(上記の手順で説明)
  • CRX ログファイルで、破損したノードの UUIDs を見つけます。
  • 元のリポジトリで、整合性チェックを実行し、これらのノードのみで修正します。

整合性チェックを制限し、ノードのリストに修正するには、これらのノードの UUIDs を設定オプション「consistencyCheckUUIDs」に追加します:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyCheckUUIDs" value="ea9cb12f-8a8f-4820-88b1-6d1c496a07cd,741c905c-cfb0-422f-acd4-e0a9cbde46c6" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

リポジトリ破損の防止

CRX2.2で、CRX/CQ5スタートアップの破損を防ぐために、この jvm パラメーターを追加することもできます:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true

クイックスタート CQSE サーバーを使用している場合は、JVM_OPTS 変数にパラメーターを追加することもできます。例えば:

crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

または crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

注意:

validateheirarchy システム・プロパティーを使用すると、リポジトリーのセッションセーブ操作のパフォーマンスがわずかに低下します。この機能を使用する場合は、ロードテストを事前に実行して、どのような影響を及ぼすかを確認することをお勧めします。特に、write-heavy アプリケーションがある場合に適用されます。

注意:

Tar 最適化と整合性チェックが並行して行われることを避けるために整合性チェックが計画されているとき、c ディスエーブル disable TAR が最適化されていることを確認してください

影響を受けるバージョン

1.X, 2.X

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー