ÃÛ¶¹ÊÓƵ

DocumentationAEM 6.5User Guide

Upgrade Procedure upgrade-procedure

Last update: Wed Apr 24 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • Admin
NOTE
The upgrade requires downtime for the Author tier as most ÃÛ¶¹ÊÓƵ Experience Manager (AEM) upgrades are performed in-place. By following these best practices, you can minimize or eliminate Publish tier downtime.

When upgrading your AEM environments, you must consider the differences in approach between upgrading author environments or publish environments to minimize downtime for both you authors and end users. This page outlines the high-level procedure for upgrading an AEM topology currently running on a version of AEM 6.x. Because the process differs between author and publish tiers and Mongo and TarMK based deployments, each tier and microkernel has been listed in a separate section. When executing your deployment, ÃÛ¶¹ÊÓƵ recommends first upgrading your author environment, determining success, and then proceeding to the publish environments.

TarMK Author Tier tarmk-author-tier

Starting Topology starting-topology

The assumed topology for this section consists of an Author server running on TarMK with a Cold Standby. Replication occurs from the Author server to the TarMK publish farm. While not illustrated here, this approach can also be used for deployments that use offloading. Make sure to upgrade or rebuild the offloading instance on the new version after disabling replication agents on the Author instance and before re-enabling them.

tarmk_starting_topology

Upgrade Preparation upgrade-preparation

upgrade-preparation-author

  1. Stop content authoring.

  2. Stop the standby instance.

  3. Disable replication agents on the author.

  4. Run the pre-upgrade maintenance tasks.

Upgrade Execution upgrade-execution

execute_upgrade

  1. Run the in-place upgrade.

  2. Update the Dispatcher module if needed.

  3. QA validates the upgrade.

  4. Shut down the author instance.

If Successful if-successful

if_successful

  1. Copy the upgraded instance to create a Cold Standby.

  2. Start the Author instance.

  3. Start the Standby instance.

If Unsuccessful (Rollback) if-unsuccessful-rollback

rollback

  1. Start the Cold Standby instance as the new Primary.

  2. Rebuild the Author environment from the Cold Standby.

MongoMK Author Cluster mongomk-author-cluster

Starting Topology starting-topology-1

The assumed topology for this section consists of a MongoMK Author cluster with at least two AEM Author instances, backed by at least two MongoMK databases. All Author instances share a datastore. These steps should apply to both S3 and File datastores. Replication occurs from the Author servers to the TarMK Publish farm.

mongo-topology

Upgrade Preparation upgrade-preparation-1

mongo-upgrade_prep

  1. Stop content authoring.
  2. Clone the data store for backup.
  3. Stop all but one AEM Author instance, your primary Author.
  4. Remove all but one MongoDB node from the replica set, your primary Mongo instance.
  5. Update the DocumentNodeStoreService.cfg file on the primary Author to reflect your single member replica set.
  6. Restart the primary Author to ensure that it restarts properly.
  7. Disable replication agents on the primary Author.
  8. Run pre-upgrade maintenance tasks on the primary Author instance.
  9. If necessary, upgrade MongoDB on the primary Mongo instance to version 3.2 with WiredTiger.

Upgrade Execution Upgrade-execution-1

mongo-execution

  1. Run an in-place upgrade on the primary Author.
  2. Update the Dispatcher or Web Module if needed.
  3. QA validates the upgrade.

If Successful if-successful-1

mongo-secondaries

  1. Create new 6.5 Author instances, connected to the upgraded Mongo instance.

  2. Rebuild the MongoDB nodes that were removed from the cluster.

  3. Update the DocumentNodeStoreService.cfg files to reflect the full replica set.

  4. Restart the Author instances, one at a time.

  5. Remove the cloned data store.

If Unsuccessful (Rollback) if-unsuccessful-rollback-2

mongo-rollback

  1. Reconfigure the secondary Author instances to connect to the cloned data store.

  2. Shut down the upgraded Author primary instance.

  3. Shut down the upgraded Mongo primary instance.

  4. Start up the secondary Mongo instances with one of them as the new primary.

  5. Configure the DocumentNodeStoreService.cfg files on the secondary Author instances to point to the replica set of not yet upgraded Mongo instances.

  6. Start up the secondary Author instances.

  7. Clean up the upgraded author instances, Mongo node, and data store.

TarMK Publish Farm tarmk-publish-farm

TarMK Publish Farm tarmk-publish-farm-1

The assumed topology for this section consists of two TarMK publish instances, fronted by Dispatchers that are in turn fronted by a load balancer. Replication occurs from the Author server to the TarMK Publish farm.

tarmk-pub-farmv5

Upgrade Execution upgrade-execution-2

upgrade-publish2

  1. Stop traffic to the Publish 2 instance at the load balancer.
  2. Run pre-upgrade maintenance on Publish 2.
  3. Run an in-place upgrade on Publish 2.
  4. Update the Dispatcher or Web Module if needed.
  5. Flush the Dispatcher cache.
  6. QA validates Publish 2 through the Dispatcher, behind the firewall.
  7. Shutdown Publish 2.
  8. Copy the Publish 2 instance.
  9. Start Publish 2.

If Successful if-successful-2

upgrade-publish1

  1. Enable traffic to Publish 2.
  2. Stop traffic to Publish 1.
  3. Stop the Publish 1 instance.
  4. Replace the Publish 1 instance with a copy of Publish 2.
  5. Update the Dispatcher or Web Module if needed.
  6. Flush the Dispatcher cache for Publish 1.
  7. Start Publish 1.
  8. QA validates Publish 1 through the Dispatcher, behind the firewall.

If Unsuccessful (Rollback) if-unsuccessful-rollback-1

pub_rollback

  1. Create a copy of Publish 1.
  2. Replace the Publish 2 instance with a copy of Publish 1.
  3. Flush the Dispatcher cache for Publish 2.
  4. Start Publish 2.
  5. QA validates Publish 2 through the Dispatcher, behind the firewall.
  6. Enable traffic to Publish 2.

Final Upgrade Steps final-upgrade-steps

  1. Enable traffic to Publish 1.
  2. QA performs final validation from a public URL.
  3. Enable replication agents from the Author environment.
  4. Resume content authoring.
  5. Perform post-upgrade checks.

final

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2