MongoBlobStore not supported for inplace upgrade? | Community
Skip to main content
J
JE_Bailey
Level 3
October 16, 2015
Solved

MongoBlobStore not supported for inplace upgrade?

  • October 16, 2015
  • 4 replies
  • 1913 views

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

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 Abhinav_Sap

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

4 replies

A
Abhinav_SapAccepted solution
Level 2
October 16, 2015

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

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

Hi,

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

kind regards,
Jörg

J
JE_BaileyAuthor
Level 3
October 16, 2015

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.

J
JE_BaileyAuthor
Level 3
October 16, 2015

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.

Terms & ConditionsAccessibility statement

Loading footer...