AEM 6.5 - Out-of-band re-indexing using oak-run tool | Community
Skip to main content
Level 3
September 26, 2020
Solved

AEM 6.5 - Out-of-band re-indexing using oak-run tool

  • September 26, 2020
  • 1 reply
  • 1377 views

Hi,

 

We are working on AEM 6.5 having shared S3 datastore. We have found few corrupt OOTB indexes in our instance. We are looking to perform re-indexing to make those corrupt indexes valid. Due to some performance related issues on our Live environment, we are planning to take out-of-band approach to perform re-indexing on clone instance and upload generated index file from clone instance to Live environment.

Just wanted to check, whether this approach(out-of-band) is possible on AEM having shared S3 datastore? Is there anyone who has taken out-of-band approach for shared S3 datastore?

 

Reference Document : 

https://docs.adobe.com/content/help/en/experience-manager-65/deploying/deploying/indexing-via-the-oak-run-jar.html#out-of-bandre-indexingtarmkusingoak-run-jar

 

https://docs.adobe.com/content/help/en/experience-manager-learn/foundation/administration/use-oak-run-jar-to-manage-indexes.html#tarmk-out-of-band-indexing-with-oak-runjar

 

Thanks.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by aemmarc2

Why not just re-index while the instance is up? 

 

1) Go to /system/console/status-oak-index-stats and make note of the indexes that are corrupted and while indexing lanes are corrupted.

2) Go to /system/console/slinglog and define an INFO level logger for org.apache.jackrabbit.oak.plugins.index.IndexUpdate and have it write to its own file

3) Go to the JMX console /system/console/jmx

4) Find the CheckpointManager mbean

5) Invoke the listCheckpoints() method -- it will print a table of checkpoints and their id numbers -- there will be at-least 2 rows, there could be more. 

6) Make note of the checkpoint Id numbers for the lanes that are corrupted -- put these id's in a text file 

7) invoke the releaseCheckpoint(java.lang.String p1) method -- passing in a single id from your text file at a time.

8 ) Go to /crx/de -- /oak:index/<whatever the corrupted index is>

9) Change the boolean 'reindex' property to true. 

10) Save and repeat 8-9 for all indexes listed in step 1

11) tail the log from step 2

 

Good luck

 

1 reply

aemmarc2Adobe EmployeeAccepted solution
Adobe Employee
September 28, 2020

Why not just re-index while the instance is up? 

 

1) Go to /system/console/status-oak-index-stats and make note of the indexes that are corrupted and while indexing lanes are corrupted.

2) Go to /system/console/slinglog and define an INFO level logger for org.apache.jackrabbit.oak.plugins.index.IndexUpdate and have it write to its own file

3) Go to the JMX console /system/console/jmx

4) Find the CheckpointManager mbean

5) Invoke the listCheckpoints() method -- it will print a table of checkpoints and their id numbers -- there will be at-least 2 rows, there could be more. 

6) Make note of the checkpoint Id numbers for the lanes that are corrupted -- put these id's in a text file 

7) invoke the releaseCheckpoint(java.lang.String p1) method -- passing in a single id from your text file at a time.

8 ) Go to /crx/de -- /oak:index/<whatever the corrupted index is>

9) Change the boolean 'reindex' property to true. 

10) Save and repeat 8-9 for all indexes listed in step 1

11) tail the log from step 2

 

Good luck