Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Inplace upgrade from 5.6.1 to aem 6.2

Avatar

Level 1

Hello,

I'm doing a inplace upgrade form 5.6.1 to aem 6.2, actually to 6.4 but its recommended to take a hop.

Following this Upgrading to AEM 6.2 for same.

On Dev server, repo size is 280GB.

Performed consistency and traversal check which took around 3 days.

Later ran crx2oak command.

java -Xmx32G -XX:MaxPermSize=4096m -jar cq5-author-p4502.jar -v -x crx2oak -xargs -- -o migrate

Set log level to 'info' (Is this correct or what can be for such a huge repo?).

Oak migration has finished in around 7-8 hours and reindexing is still happening from past 6 days.

It looked unusual to me.

Please help if the approach i'm following is correct and is usual.

Any specific preupgrade steps needs to be performed before executing the oak migration command.?

Using latest version of crx2oak migration tool helps.?

any key include & exclude paths to be given while running the crx2oak command

I'm worried, Coz the production is around 480GB and cannot wait for days to finish the inplace upgrade

Please share a guide or any kind of SOP/document if someone has done same practice earlier.

8 Replies

Avatar

Employee

Hello,

I hope you are using AEM 6.2 jar to run crx2oak.

java -Xmx32G -XX:MaxPermSize=4096m -jar cq5-author-p4502.jar -v -x crx2oak -xargs -- -o migrate.

Use the crx2oak bundled with AEM 6.2

Also, can you check your index logs . Are the logs looping? It might be possible that re-indexing is failing. Can you upload your logs for review.

Best would be to open a daycare ticket so that we can take a closer look into your system.

Regards,

Manish Singh

Avatar

Level 2

Hello,

Yes the jar used to run the crx2oak was of AEM 6.2.

The indexing got finished today after 7 days. But we cannot wait for days to finish the in place upgrade on other servers. Please suggest any way to migrate 480 GB repository in a short span of time.

Regards,

Nishita

Avatar

Employee

You have a large repository and hence it's expected that a migration/upgrade will take significant time. You can try to clean your CQ 5.6.x repository manually to reduce the total number of nodes to migrate over to AEM 6.x.

1. Stop all replication agents, workflows and launchers.

2. Make sure that you stop, terminate all workflows instances.

3. Using content explorer (or CRXDE) create /tmp/todelete folder

4. Move the following folders to /tmp/todelete

• /var/audit

• /var/eventing/jobs

• /var/replication/data

• /etc/workflow/instances

After you move workflow instances node, you must immediately recreate an empty /etc/workflow/instances folder with exactly same properties)

5. Review /etc/packages folder and check if there any big in file size *.zip archives that you do not necessarily need to keep.

6. Stop and start CQ

7. Begin deleting recursively /tmp/todelete.

8. Run tar optimization.

9. Run datastore GC.

10. Run a consistency check. It is a good practice to re-build indexes along with a consistency check:

  • Stop CQ.
  • Delete all index*.tar files and locks if exists from the following locations:
    • \crx-quickstart\repository\workspaces\crx.default
    • \crx-quickstart\repository\version
    • \crx-quickstart\repository\tarJournal
  • Edit the following configuration files:
    • \crx-quickstart\repository\repository.xml

                       and

  • \crx-quickstart\repository\workspaces\crx.default\workspace.xml.
  • Search for all <SearchIndex class="..."> element in both xml files and add three parameters:
    • <param name="enableConsistencyCheck" value="true"/>
    • <param name="forceConsistencyCheck" value="true"/>
    • <param name="autoRepair" value="true"/>
  • Search for all <PersistenceManager class="..."> element in both xml files and add two parameters:
    • <param name="consistencyCheck" value="true" />
    • <param name="consistencyFix" value="true" />
  • Check an example in KB [1]. Pay attention, that in repository.xml those changes was also added to Versioning section.
  • Start CQ.

Avatar

Employee

I've successfully done CQ 5.6.1 straight to AEM 6.5.


Where are you seeing that you need to do an interim-upgrade to 6.2 first?

Avatar

Employee Advisor

I think he has 5.6 repository with crx2 backend. He is using "-- -o migrate" in tne migrate command.

Avatar

Level 1

I'm assumed that there would be a chance of failure if you're doing it straight to aem 6.4 for various reasons. Also repository needs to go through crx2oak migration.

Can you help me understand how you achieved straight from 5.6.1 straight to AEM 6.5 (Upgrade doc or Process steps, pre-upgrade, U-grade & post-upgrade). I will try to relate it to my scenario and check for possibilities.

Avatar

Employee Advisor

There is no need for intermediate upgrade to 6.2, you should be able to directly able to upgrade from 5.6.1 to 6.4. The hop is only necessary when moving from any version older than 5.6.

Detailed upgrade steps at [1]

[1] https://helpx.adobe.com/experience-manager/6-4/sites/deploying/using/in-place-upgrade.html

Avatar

Employee

Follow what berliant​ outlined.

Think of it as 3 main operations that need to be done in order:

1) Unpack the 6.4 or 6.5 jar file over the CQ 5.6 instance. So place that alongside the cq5.6 jar and unpack.

java -Xmx4096m -jar cq-quickstart-6.4.0.jar -unpack


2) Perform repository / segmentstore migration -- this is where we make the jump from crx2 used in cq5.6 to oak-segment-tar used in aem 6.4 or 6.5.

java -Xmx4096m -jar cq-quickstart-6.4.0.jar -v -x crx2oak -xargs -- --load-profile segment-fds

3) Perform the actual upgrade. Do this by starting the 6.4/6.5 quickstart jar without (important) any scripts.

java -server -Xmx4096m -XX:MaxPermSize=256M -Djava.awt.headless=true -Dsling.run.modes=author,crx3,crx3tar -jar cq-quickstart-6.4.0.jar start -c crx-quickstart -i launchpad -p 4502 -Dsling.properties=conf/sling.properties

--

Monitor the upgrade.log and error.log

In upgrade.log look for : c.a.g.c.e.MigrationRunner: migration COMPLETED