WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId - Unknown parent node with id ...ERROR ... failed to read bundle: ...
Diese Probleme können mehrere Ursachen haben. Mögliche Ursachen (abhängig von der CRX-Version) sind:
Die häufigste Ursache ist die gleichzeitige Änderung, während dieselbe Sitzung benutzt wird. In diesem Fall enthält die Datei CRX error.log höchstwahrscheinlich mindestens eine ConcurrentModificationException.
Diese Symptome deuten darauf hin, dass der Index (und möglicherweise auch der Arbeitsbereich) inkonsistent sein können.
Normalerweise ist die Auswirkung einer Inkonsistenz gering. Ein Problem besteht darin, dass die Logdatei aufgrund einer Inkonsistenz mit Fehlermeldungen gefüllt ist.
Suchindexinkonsistenzen können aufgrund folgender Ursachen auftreten:
Es gibt zwei Möglichkeiten, um Suchindexinkonsistenzen zu korrigieren:
Sie können beim Start eine Indexkonsistenzprüfung durchführen. Fügen Sie in der workspace.xml zwei Parameter im Element <SearchIndex class="..."> hinzu:
<param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/>
Ein dritter Parameter steuert, ob Fehler repariert werden sollen oder ob sie nur protokolliert werden sollen:
<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>
Wenn Sie Ihren Suchindex neu erstellen, werden alle Suchindexinkonsistenzen korrigiert. Es dauert jedoch wesentlich länger als die Konsistenzprüfung und Korrektur des Suchindex. Aus diesem Grund sollten Sie bei der Planung einer Neuerstellung des Suchindexes besonders vorsichtig sein, und wenn Sie sich nicht viele Ausfallzeiten leisten können, sollten Sie in Erwägung ziehen, stattdessen eine Überprüfung und Korrektur durchzuführen.
Planung der Neuerstellung Ihres Indexes.
Da die erforderliche Zeit für die Neuerstellung Ihres Indexes von vielen verschiedenen Faktoren abhängt (zum Beispiel der Gesamtanzahl der Knoten, Größe der Asset-Dateien und Asset-Dateitypen), sollten Sie zuerst die Wiederherstellung in einer Nicht-Produktionsumgebung testen. Verwenden Sie den Nicht-Produktionstest, um zu berechnen, wie lange Sie ein Ausfallfenster in der Produktion benötigen werden. Kleine Repositorys mit einer Größe von 2 bis 10 GB können 30 Minuten bis 6 Stunden in Anspruch nehmen, größere 6 Stunden bis 2 Tage.
Wie Sie den Index neu erstellen.
Gehen Sie folgendermaßen vor, um Ihren Suchindex neu zu erstellen:
Wenn das nicht hilft und Fehler gedruckt werden, welche nicht repariert werden können, sind die Arbeitsbereichsdaten wahrscheinlich inkonsistent.
Persistenz-Managers können die Repository-Konsistenz überprüfen und Probleme beim Start korrigieren. Um die Konsistenzprüfung zu aktivieren und Probleme automatisch zu korrigieren, fügen Sie die folgenden Parameter in der repository.xml und workspace.xml innerhalb jedes <PersistenceManager class="...">-Elements hinzu und starten Sie CRX erneut.
In einer Standardinstallation von CQ5.2.x finden Sie diese Dateien unter crx-quickstart/repository/workspaces/*/workspace.xml und crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.
In CQ5.3 kann die repository.xml stattdessen unter crx-quickstart/repository/repository.xml gefunden werden.
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
Bei nächsten Neustart wird eine Überprüfung bzw. Korrektur (Index oder Persistenz-Manager) ausgeführt. Nachdem die Konsistenzprüfung abgeschlossen ist, deaktivieren Sie die entsprechenden Einstellungen, da sonst beim Start von CRX die Konsistenzprüfung immer ausgeführt wird.
Wenn nur die Konsistenzprüfung aktiviert ist, wird eine Datei inconsistentBundleIds.txt im Arbeitsbereichsverzeichnis erstellt.
Wenn nur consistencyFix aktiviert ist, wird die Datei inconsistentBundleIds.txt gelesen und die Knoten werden korrigiert. Die Datei wird dann gelöscht, wenn alles korrigiert werden konnte.
Führen Sie eine Konsistenzkorrektur in einer Clusterumgebung nur auf einem Clusterknoten aus. Starten Sie keine anderen Clusterknoten, während die Konsistenzkorrektur ausgeführt wird. Nachdem sie beendet ist, können die anderen Clusterknoten gestartet werden.
Die Konsistenzprüfung untersucht alle Knoten und ist daher langsam. Ziehen Sie in Betracht, die Konsistenzprüfung auf einer Kopie des Repositorys auszuführen und dann nur die beschädigten Knoten zu reparieren, um die Wartungszeit zu reduzieren. Verwenden Sie dazu die folgenden Schritte:
Um die Konsistenzprüfung und Korrektur auf eine Liste von Knoten zu beschränken, fügen Sie die UUIDs dieser Knoten in zu der Konfigurationsoption „consistencyCheckUUIDs“ hinzu:
<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>
Ab CRX 2.2 können Sie diesen JVM-Parameter dem CRX-/CQ5-Start hinzufügen, um Beschädigungen zu vermeiden:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true.
Wenn Sie den CQSE-Schnellstart-Server verwenden, können Sie den Parameter zur JVM_OPTS-Variable hinzufügen, zum Beispiel:
crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
oder crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true.
Die Verwendung der Systemeigenschaft validateheirarchy führt zu einer leichten Verschlechterung der Leistung von Sitzungsspeichervorgängen im Repository. Wenn Sie vorhaben, diese Funktion zu verwenden, sollten Sie zuerst einen Lasttest machen, um festzustellen, welche Auswirkung die Funktion hat. Dies trifft besonders dann zu, wenn Sie eine schreibintensive Anwendung haben.
Stellen Sie sicher, dass die Tar-Optimierung deaktiviert ist, wenn die Konsistenzprüfung ausgeführt werden soll, um zu vermeiden, dass parallel die Tar-Optimierung und die Konsistenzprüfung ausgeführt werden.
1.X, 2.X.
Bei Ihrem Konto anmelden