Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events
SOLVED

MongoBlobStore not supported for inplace upgrade?

Avatar

Level 3

We're planning to use Mongo to support distributed clustering and we were recently told, in the middle of our upgrade, that it was not possible to do an in place upgrade to mongo with the MongoBlobStore, that we would be forced to use the File storage plugin, which sort of defeats the purpose of clustering :) I was wondering if I could get a more technical explanation of why that doesn't work.

TIA

1 Accepted Solution

Avatar

Correct answer by
Level 2

This might not be the answer you are looking for. Normally in place upgrade is preferred for version history migration. If that is why you are going with in place upgrade, you can do fresh install and deployment and then package version history with filter rules, like this - /jcr:system/jcr:versionStorage 
My experience has been that fresh install instead of in place upgrade gives a new lease to your AEM instance and will be more performant (at least for a while :))

Abhinav

View solution in original post

4 Replies

Avatar

Correct answer by
Level 2

This might not be the answer you are looking for. Normally in place upgrade is preferred for version history migration. If that is why you are going with in place upgrade, you can do fresh install and deployment and then package version history with filter rules, like this - /jcr:system/jcr:versionStorage 
My experience has been that fresh install instead of in place upgrade gives a new lease to your AEM instance and will be more performant (at least for a while :))

Abhinav

Avatar

Employee Advisor

Hi,

what's the architecture where you're coming from? TarPM cluster?

kind regards,
Jörg

Avatar

Level 3

Jörg Hoh wrote...

Hi,

what's the architecture where you're coming from? TarPM cluster?

kind regards,
Jörg

 

 

Yes, right now, we have clustered author instances with TarPM and an international author base. Which encounters performance issues, we are looking at ways to put one or more author instances closer to some of the authors. Additionally,  moving forward, we eventually want to have two clusters in the publish level, with each cluster consisting of geographically disbursed cluster members.

Avatar

Level 3

Abhinav_Sap wrote...

This might not be the answer you are looking for. Normally in place upgrade is preferred for version history migration. If that is why you are going with in place upgrade, you can do fresh install and deployment and then package version history with filter rules, like this - /jcr:system/jcr:versionStorage 
My experience has been that fresh install instead of in place upgrade gives a new lease to your AEM instance and will be more performant (at least for a while :))

Abhinav

 

I'll definitely take a look at that, quite honestly the reason we are looking at an in place versus a migration is that we consistently run into problems with content migration. The only method that I've seen work consistently is to package stuff up and we have far to much content for that to be effective.