MongoBlobStore not supported for inplace upgrade?

[JE_Bailey]

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

[Abhinav_Sap · Accepted solution]

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

[Jörg_Hoh]

Hi,

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

kind regards,
Jörg

[JE_Bailey]

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.

[JE_Bailey]

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.