Debugging von SegmentNotFoundException bei Problemen in AEM 6.x

In diesem Artikel erfahren Sie, wie Sie SegmentNotFoundException debuggen, wenn in AEM 6.x ein Problem gemeldet wird, indem Sie zur letzten bekannten guten Revision des Segmentspeichers zurückkehren.

Beschreibung description

Umgebung

Experience Manager 6.x

Problem/Symptome

Das Fehlerprotokoll zeigt eine Ausnahme vom Typ SegmentNotFound , wie im folgenden Beispiel gezeigt:

org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment d2c720c4-c146-4ab1-ac37-542aad93c33f not found at

org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:602) at

org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:542) at

org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:95) at

org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:542) at

org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:125) at

org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70) at

org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:424) at

org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433) at

org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391) at

org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:608) at

org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) at

org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442) at

org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:490) at

org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433) at

org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:608) at

org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) at

org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:695) at

org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.runWhenPermitted(AsyncIndexUpdate.java:543) at

org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:402) at

org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118) at

org.quartz.core.JobRunShell.run(JobRunShell.java:202) at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at

java.lang.Thread.run(Thread.java:745)

Auflösung resolution

Schritte zum Auflösen

Es gibt zwei Ansätze, um das Problem zu beheben und die Inkonsistenzen im Repository zu beseitigen

Kehren Sie zur letzten zweifelsfrei funktionierenden Revision des Segmentspeichers zurück.

Verwenden Sie zunächst das Tool "oak run", bei dem es sich um eine ausführbare JAR handelt.[ 1] enthält alles, was Sie für eine einfache Oak-Installation und die Ausführung von oak-bezogenen Vorgängen benötigen.

Der Prüfmodus von oak-run kann verwendet werden, um die letzte zweifelsfrei funktionierende Revision eines Segmentspeichers zu ermitteln.  Dies kann verwendet werden, um einen beschädigten Segmentspeicher manuell auf die neueste gute Revision zurückzusetzen.

Vorsicht: Durch diesen Prozess werden die Daten im System auf einen vorherigen Zeitpunkt zurückgesetzt.  Wenn Sie vermeiden möchten, dass Änderungen in Ihrem System verloren gehen, können Sie stattdessen die Option B verwenden.

So führen Sie die Prüfung und Wiederherstellung durch:

  1. Laden Sie von https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run eine Version von oak-run herunter, die Ihrer Oak-Core-Version entspricht.

  2. Um einen beschädigten Segmentspeicher auf den neuesten guten Status zurückzusetzen, wechseln Sie in das Arbeitsverzeichnis von CQ (das Verzeichnis, das den Ordner crx-quickstart enthält) und sichern Sie alle Dateien in ./crx-quickstart/repository/segmentstore/.

  3. Führen Sie die Konsistenzprüfung durch.

    java -Xmx6000m -jar oak-run-*.jar check —bin=-1 /path/to/crx-quickstart/repository/segmentstore

    Dadurch werden die Revisionen rückwärts durchsucht, bis eine konsistente gefunden wird:

    Suchen Sie nach einer Nachricht wie der folgenden:

    code language-none
    main INFO o.a.j.o.p.s.f.t.ConsistencyChecker - Found latest good revision afdb922d-ba53-4a1b-aa1b-1cb044b535cf:234880
    
  4. Stellen Sie das Repository durch Bearbeiten auf diese Revision zurück./crx-quickstart/repository/segmentstore/journal.log und Löschen aller Zeilen nach der Zeile, die die neueste gute Revision enthält.

  5. Entfernen Sie alle ./crx-quickstart/repository/segmentstore/*.bak-Dateien.

  6. Führen Sie mit dem folgenden Befehl eine Checkpoint-Bereinigung aus, um verwaiste Checkpoints zu entfernen:

    code language-none
    java -Xmx6000m -jar oak-run-*.jar checkpoints /path/to/crx-quickstart/repository/segmentstore rm-unreferenced
    
  7. Komprimieren Sie schließlich das Repository:

    java -Xmx6000m -jar oak-run-*.jar compact /path/to/crx-quickstart/repository/segmentstore/

Es kann vorkommen, dass die Oak-Run-Prüfung die richtige Revision nicht finden kann und wir beim Ausführen des Prüfbefehls "ConsistencyChecker - No good revision found"erhalten.

Korruptionsbehebung bei der Konsistenzprüfung mit "ConsistencyChecker - No good revision found"

Entfernen Sie beschädigte Knoten manuell.

Sie können Folgendes in AEM, TarMK-Setups ohne konfigurierten FileDatastore und in Situationen tun, in denen die Binärdateien beschädigt sind.

Vorsicht: Die unten beschriebene Vorgehensweise richtet sich an fortgeschrittene Benutzer.  Beim Löschen der beschädigten Knoten müssen Sie sicherstellen, dass es sich nicht um Systemknoten handelt (z. B. /home, /jcr:system usw.).  Wenn es sich um Systemknoten handelt, müssen Sie sicherstellen, dass Sie diese wiederherstellen können.  Wenden Sie sich an das AEM Kundenunterstützungs-Team, um Unterstützung bei den hier beschriebenen Schritten zu erhalten, wenn Sie sich nicht sicher sind.

  1. Beenden Sie AEM.

  2. Verwenden Sie die Oak-Ausführungskonsole und laden Sie das childCount-Groovy-Skript, um die beschädigten Knoten im Segmentspeicher zu identifizieren:

    Laden Sie die Oak-Run-Konsolen-Shell:

    code language-none
    java -jar oak-run-*.jar console crx-quickstart/repository/segmentstore
    

    Führen Sie die beiden folgenden Befehle in der Shell aus, um das Skript zu laden und auszuführen:

    code language-none
    :load https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy
    countNodes(session.workingNode)
    

    Dies führt zur folgenden Ausgabe, die den Pfad zu den beschädigten Knoten angibt:

    code language-none
    21:21:42.029 main ERROR o.a.j.o.p.segment.SegmentTracker - Segment not found: 63ae05a4-b506-445c-baa2-cfa1b13b6e2f. Creation date delta is 3 ms.
    warning unable to read node /content/dam/test.txt/jcr:content/renditions/original/jcr:content
    

    In einigen Fällen ist das Problem mit binären Eigenschaften verknüpft und das childCount Groovy-Skript kann keine beschädigten Knoten finden.  In diesen Fällen können Sie stattdessen den folgenden Befehl verwenden, mit dem die ersten 1024 Byte für jede während der Durchlaufphase aufgefundene Binärdatei gelesen werden (beachten Sie, dass dieser Befehl langsamer ist und nur verwendet werden sollte, wenn das oben genannte nicht die erwarteten Ergebnisse zurückgibt):

    code language-none
    countNodes(session.workingNode,true)
    
  3. Entfernen Sie alle identifizierten beschädigten Knoten, die in der Ausgabe des letzten Befehls mit rmNodes.groovy aufgelistet sind. Laden Sie die Oak-Run Console-Shell mit dem folgenden Befehl:

    code language-none
    java -jar oak-run-*.jar console crx-quickstart/repository/segmentstore
    

    Laden Sie das Skript „groovy“:

    code language-none
    :load
    https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovy
    

    Führen Sie den Befehl rmNode aus, um den beschädigten Knoten zu entfernen, ersetzen Sie /path/to/corrupt/node durch den Pfad zum beschädigten Knoten, den Sie entfernen müssen.

    code language-none
    rmNode(session, "/path/to/corrupt/node")
    

    wobei der beschädigte Knotenpfad der in Schritt 2 abgerufene Pfad ist, z. B.: "/content/dam/test.txt/jcr:content/renditions/original/jcr:content/"

    Hinweis: Wenn Sie oak-run.jar Version 1.6.13 und höher verwenden, setzen Sie den JVM-Parameter —read-write , wenn ein Fehler wie folgt auftritt:

    code language-none
    / rmNode(session,"/path/to/corrupt/node")    Removing node /path/to/corrupt/node    ERROR java.lang.UnsupportedOperationException:    Cannot write to read-only store    at org.apache.jackrabbit.oak.segment.SegmentWriterBuilder$1.execute (SegmentWriterBuilder.java:171)    at org.apache.jackrabbit.oak.segment.SegmentWriter.writeNode (SegmentWriter.java:318)    at org.apache.jackrabbit.oak.segment.SegmentNodeBuilder.getNodeState (SegmentNodeBuilder.java:111)    at org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.init (SegmentNodeStore.java:581)    at org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge (SegmentNodeStore.java:333)    at org.apache.jackrabbit.oak.spi.state.NodeStore$merge.call (Unknown Source)    at groovysh_evaluate.rmNode (groovysh_evaluate:11)
    
  4. Wiederholen Sie Schritt 3 für alle Knoten, die in Schritt 2 gefunden wurden.

    Dieser obige rmNode-Befehl sollte für den beschädigten Pfad "true"zurückgeben, was bedeutet, dass er ihn gelöscht hat. Stellen Sie sicher, dass diese drei gefundenen beschädigten Pfade gelöscht werden, indem Sie den Befehl rmNode auf diesen Pfaden erneut ausführen. Bei der nächsten Ausführung sollte "false"zurückgegeben werden.
    Wenn Sie feststellen, dass im Repository immer noch dieselben Pfade vorhanden sind, verwenden Sie die gepatchte Version von oak-run jar, d. h. oak-run-1.2.18-NPR-17596. Diese Version von jar überspringt unlesbare Binärdateien bei der Komprimierung, ersetzt sie durch 0-Byte-Binärdateien und protokolliert die Ausnahme und den Pfad zum Server. Das resultierende komprimierte Repository sollte dann die Oak-Run-Prüfung und das Knotenzählungsskript übergeben und Sie sollten es auch mit einem nicht gepatchten Oak-Run erneut komprimieren können.

  5. Führen Sie eine Checkpoint-Bereinigung durch, indem Sie Checkpoints wie unten beschrieben auflisten. Wenn es mehr als einen Checkpoint gibt, bereinigen Sie ihn:

    code language-none
    nohup java -Xmx4096m -jar oak-run-1.2.18.jar checkpoints /app/AEM6/author/crx-quickstart/repository/segmentstore rm-allnohup.out
    
  6. Führen Sie eine Offline-Komprimierung aus. Wenn Sie nicht wissen, wie Sie die Offline-Verdichtung ausführen, lesen Sie here.

  7. Starten Sie den Server und warten Sie, bis die Indizierung abgeschlossen ist.

Ursache

Eine SegmentNotFoundException im Fehlerprotokoll bedeutet, dass ein Segment nicht mehr vorhanden ist, obwohl offenbar versucht wird, weiterhin darauf zuzugreifen. Hierfür gibt es im Großen und Ganzen drei verschiedene Ursachen: Das Segment wurde durch manuelles Eingreifen entfernt (z. B. rm -rf /), das Segment wurde durch Revisionsbereinigung entfernt oder das Segment kann aufgrund eines Fehlers im Code nicht gefunden werden.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f