Deployment with AEM6 with MongoMK

[kbh_emakina]

Hi,

I'm currently on a project where we move from AEM 5.6.1 (TarPM) to AEM 6 with MongoMK. 

The current deployment procedure with 2 publish nodes is to update 1 at a time and use a load balancer to exclude the one currently being updated; Result: No downtime.

With the MongoMK there is now a central database so a phased deployment looks no longer possible.

A solution might be:

1. exclude a publish node (A) from the load balancer.
2. block all usergenerated content input on the remaining nodes.
3. copy the aem-publish database to aem-publish-next-release
4. point publish node A to the newly created database
5. deploy the new code on publish A 
6. re-include publish node in the load balancer pool.
6. gradually point the remaining nodes to the new database.
7. if everything completed successfully, remove the old database.
8. re-activate usergenerated content input

Surely there is a better way... Anyone else dealing with this?

Thank you.

Kris.
 

[Sham_HC]

Since db is shared among all publish instance your approach looks ok to me unless you have standby server exists.   Since you are blocking ugc for while why don;t you do all at once.

*  Configure dispatcher to serve stale .

At the time of deployment

• Take a backup.
• tcp reset so that dispatcher don;t see the publish & block ugc.
• Deploy the code & verify everything is ok in publish.
• If not ok & decided to revert, restore from backup or uninstall your code.
• Once approved allow dispatcher to access publish & needed (Based on deployment changes) refill the dispatcher cache. Offcourse enable ugc.

[kbh_emakina]

Thanks for your reply.

The reason why we would not go for a full static intermediate state, is that we have business critical services running that don't allow for downtime (SLA agreement).

In a phased approach these would still be available.

Lots of application servers support a staged approach within the container, but this is not available in the AEM standalone version. Which we have used upon till now and would like to continue to use.

[vinaym64638896]

I am just wondering why we cannot use the author to manage the down time and do the reverse replication for the publish while the upgrade is going on.

It seems it’s would help us in this case if the Author is used to replicate data to the new CQ6 with mongo and once the replication is done you can upgrade the next publish.