Felsöka SegmentNotFoundException när Problem rapporteras i AEM 6.x
Den här artikeln hjälper dig att förstå hur du felsöker SegmentNotFoundException när Issue rapporteras i AEM 6.x genom att återgå till den senaste fungerande versionen av segmentbutiken.
Beskrivning description
Miljö
Experience Manager 6.x
Problem/symtom
Felloggen visar ett SegmentNotFound-undantag, som i följande exempel:
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)
Upplösning resolution
Steg som ska åtgärdas
Det finns två sätt att åtgärda problemet och ta bort inkonsekvenser i databasen
Återgå till den senaste fungerande versionen av segmentarkivet.
Första, Använd ekkörningsverktyget, som är en körbar burk [ ] som innehåller allt du behöver för en enkel Oak-installation och ekelrelaterade åtgärder.
Kontrollkörningsläget för ekkörning kan användas för att avgöra den senaste fungerande versionen av en segmentbutik. Den kan användas för att manuellt återställa en skadad segmentbutik till den senaste bra versionen.
Varning! Den här processen återställer data i systemet till en tidigare tidpunkt. Om du inte vill förlora ändringar i systemet kan du prova alternativ B nedan i stället.
Så här utför du kontroll och återställning:
-
Hämta en version av eko-run som matchar din eke-kärnversion från https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run
-
Om du vill återställa ett skadat segmentlager till det senaste fungerande tillståndet ändrar du till CQ:s arbetskatalog (den som innehåller snabbstartmappen) och säkerhetskopierar alla filer i ./crx-quickstart/database/segmentstore/.
-
Kör konsekvenskontrollen,
java -Xmx6000m -jar oak-run-*.jar check —bin=-1 /path/to/crx-quickstart/databas/segmentstore
Detta söker bakåt genom ändringarna tills det finns en konsekvent version:
Leta efter meddelanden som nedan:
code language-none main INFO o.a.j.o.p.s.f.t.ConsistencyChecker - Found latest good revision afdb922d-ba53-4a1b-aa1b-1cb044b535cf:234880 -
Återställ databasen till den här versionen genom att redigera./crx-quickstart/repository/segmentstore/journal.log och ta bort alla rader efter raden som innehåller den senaste bra ändringen.
-
Ta bort alla ./crx-quickstart/database/segmentstore/*.bak.
-
Kör rensning av kontrollpunkter för att ta bort överblivna kontrollpunkter med följande kommando:
code language-none java -Xmx6000m -jar oak-run-*.jar checkpoints /path/to/crx-quickstart/repository/segmentstore rm-unreferenced -
Komprimera slutligen databasen:
java -Xmx6000m -jar oak-run-*.jar compact /path/to/crx-quickstart/repository/segmentstore/
Det kan finnas tillfällen när ekskörningskontrollen inte kan hitta den korrekta versionen och vi får "ConsistencyChecker - No good revision found" när vi kör kommandot check.
Så här åtgärdar du fel när ConsistencyChecker påträffas - ingen bra revision hittades vid konsekvenskontroll
Ta bort skadade noder manuellt.
Du kan göra följande i AEM, StjärtMK-inställningar utan konfigurerad FileDatastore och situationer där skador förekommer i binärfilerna.
Varning: Proceduren nedan är avsedd för avancerade användare. När du tar bort skadade noder måste du se till att de inte är systemnoder (till exempel /home, /jcr:system). Om de är systemnoder måste du se till att du kan återställa dem. Kontakta AEM kundtjänst om du är osäker.
-
Sluta AEM.
-
Använd Oak körningskonsol och läs in växlingsskriptet childCount för att identifiera skadade noder i segmentbutiken:
Läs in konsolens ekar-gränssnitt:
code language-none java -jar oak-run-*.jar console crx-quickstart/repository/segmentstoreKör de två kommandona nedan i gränssnittet för att läsa in skriptet och köra det:
code language-none :load https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy countNodes(session.workingNode)Detta resulterar i följande utdata som anger sökvägen till de skadade noderna:
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:contentI vissa fall är problemet länkat till binära egenskaper och gruppskriptet childCount kan inte hitta några skadade noder. I dessa fall kan du använda följande kommando, som läser de första 1024 byten för varje binär fil som påträffas under genomgången (observera att det här kommandot blir långsammare och bör bara användas när ovanstående inte returnerar det förväntade resultatet):
code language-none countNodes(session.workingNode,true) -
Ta bort alla identifierade skadade noder i utdata från det senaste kommandot med rmNodes.groovy
Läs in konsolskal som körs med kommandot nedan:code language-none java -jar oak-run-*.jar console crx-quickstart/repository/segmentstoreLäs in grupperingsskriptet:
code language-none :load https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovyKör kommandot rmNode för att ta bort den skadade noden, ersätt /path/to/corrupt/node med sökvägen till den skadade nod som du måste ta bort.
code language-none rmNode(session, "/path/to/corrupt/node")där den skadade nodsökvägen är sökvägen som fås i steg 2, t.ex."/content/dam/test.txt/jcr:content/renditions/original/jcr:content/"
Obs! När du använder oak-run.jar version 1.6.13 och senare, ställer du in JVM-parametern —read-write om du stöter på ett fel som:
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) -
Upprepa steg 3 för alla noder som finns i steg 2
Det här ovanstående rmNode-kommandot ska returnera true för den skadade sökvägen, vilket betyder att den har tagits bort. Se till att de hittade tre skadade sökvägarna tas bort genom att köra kommandot rmNode på de sökvägarna igen. Nästa körning ska returnera false.
Om du ser att samma sökvägar fortfarande finns i databasen kan du använda den patchade versionen av ek-run jar, d.v.s. oak-run-1.2.18-NPR-17596. I den här versionen av jar hoppas oläsbara binärfiler över vid komprimering, så att de ersätts med binärfiler på 0 byte och undantag och sökväg till systemservern loggas. Den resulterande komprimerade databasen ska sedan skicka en körkontroll och ett nodräkningsskript, och du bör även kunna komprimera den igen med en icke-patchad ekkörning. -
Utför en rensning av kontrollpunkter genom att lista kontrollpunkter med hjälp av nedan. Om det finns fler än en kontrollpunkt ska du rensa upp dem:
code language-none nohup java -Xmx4096m -jar oak-run-1.2.18.jar checkpoints /app/AEM6/author/crx-quickstart/repository/segmentstore rm-allnohup.out -
Kör en offlinekomprimering. Om du inte vet hur du kör offlinekomprimering kan du läsa här.
-
Starta servern och vänta tills indexeringen är klar.
Orsak
Ett SegmentNotFoundException i felloggen innebär att ett segment inte finns längre, även om någon försöker att fortfarande komma åt det. Det finns i stort sett tre olika grundorsaker till detta: segmentet har tagits bort manuellt (t.ex. rm -rf /), segmentet har tagits bort av skräpinsamlingen för revision eller så går det inte att hitta segmentet på grund av ett fel i koden.