MongoMK Author cluster topology during an AEM 6.5 LTS upgrade
This article explains whether reducing a MongoMK Author cluster to a single node is technically required for an in-place upgrade to AEM 6.5 LTS, or if it serves primarily as a rollback safeguard.
Description description
Environment
- Adobe Experience Manager 6.5 or AEM 6.5 LTS
- MongoMK Author cluster with multiple Author instances and a MongoDB replica set
Issue/Symptoms
- During an in-place upgrade from AEM 6.5 to AEM 6.5 LTS, you are instructed to reduce the MongoMK Author cluster to one active Author instance and the MongoDB replica set to one member.
- You need to determine whether this reduction is technically required for the upgrade or primarily serves as a rollback safeguard.
- You want to know whether the upgrade can proceed with the full MongoDB replica set and all Author instances intact.
Cause
Only one Author instance should write to the repository during the upgrade, and other tools or processes shouldn’t write to it. Adobe’s published upgrade procedure also instructs you to reduce the MongoDB replica set to one member and update the primary Author’s DocumentNodeStoreService.cfg for that topology. The source technical assessment says that retaining the full replica set can be considered if the single-writer condition and backup safeguards are met, but this differs from Adobe’s documented procedure and requires deployment-specific review.
Resolution resolution
Follow the steps below to resolve the issue:
-
Stop content authoring and ensure that only one AEM Author instance is active and writing to the repository during the upgrade.
-
Stop all other Author instances so that only the designated Author remains running and connected to MongoDB during the upgrade.
-
Choose the MongoDB topology for the upgrade:
- For Adobe’s documented upgrade procedure, temporarily reduce the MongoDB replica set to one member and update the primary Author’s
DocumentNodeStoreService.cfgto reflect the single-member replica set. - If you plan to retain the full MongoDB replica set, proceed only after the upgrade owner confirms that this topology is appropriate for your deployment.
Note: Adobe’s published upgrade procedure uses a single-member MongoDB replica set during upgrade preparation and rebuilds the removed nodes after a successful upgrade. Retaining the full replica set is an alternative identified in the technical assessment, not the default procedure in the published runbook. Validate that alternative with Adobe or a qualified AEM/MongoDB upgrade specialist before proceeding.
- For Adobe’s documented upgrade procedure, temporarily reduce the MongoDB replica set to one member and update the primary Author’s
-
Ensure that no other tools or processes write to the repository during the upgrade window.
-
Create reliable, tested backups before upgrading:
- Back up the MongoDB replica set.
- Back up the datastore, whether it uses file storage or S3.
- Back up the Author installation, including
crx-quickstart.
-
Proceed with the upgrade on the active Author instance by following Adobe’s documented
[in-place upgrade procedure](https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/implementing/deploying/upgrading/in-place-upgrade). -
After a successful upgrade, verify that the Author instance and MongoDB replica set function as expected. Note: If you used the single-member procedure, rebuild the removed MongoDB nodes, update
DocumentNodeStoreService.cfgto reflect the full replica set, and restart the Author instances one at a time, as described in Adobe’s upgrade procedure.