升级过程

升级AEM环境时，您需要考虑升级作者环境或发布环境之间的方法差异，以最大限度地减少作者和最终用户的停机时间。 本页概述了升级AEM 6.x版本上当前运行的AEM拓扑的高级过程。由于创作层和发布层以及基于Mongo和TarMK的部署之间的流程不同，因此每个层和微内核都列在单独的部分中。 执行部署时，我们建议先升级您的创作环境，确定成功与否，然后继续访问发布环境。

TarMK作者层

启动拓扑

此部分假定的拓扑由在TarMK上运行的具有冷备用的作者服务器组成。 从作者服务器复制到TarMK发布场。 虽然此处未说明，但此方法也可用于使用卸载的部署。 在作者实例上禁用复制代理后以及重新启用它们之前，请确保在新版本上升级或重新构建卸载实例。

升级准备

1. 停止内容创作

2. 停止备用实例

3. 在作者上禁用复制代理

4. 运行升级前维护任务。

升级执行

1. 运行就地升级

2. 如果需要，请更新调度程序模块​**

3. QA验证升级

4. 关闭作者实例。

如果成功

1. 复制升级的实例以创建新的Cold Standby

2. 开始创作实例

3. 开始待机实例。

如果失败（回滚）

1. 开始Cold Standby实例作为新的主实例

2. 从Cold Standby重建作者环境。

MongoMK作者群集

启动拓扑

此部分假定的拓扑由至少包含两个AEM作者实例的MongoMK作者群集组成，该实例由至少两个MongoMK数据库支持。 所有作者实例共享一个数据存储。 这些步骤应同时适用于S3和文件数据存储。 从作者服务器复制到TarMK发布场。

升级准备

1. 停止内容创作
2. 克隆数据存储以进行备份
3. 停止除一个AEM作者实例外的所有实例，即您的主作者
4. 从副本集（主Mongo实例）中删除除一个MongoDB节点外的所有节点
5. 更新主作者上的DocumentNodeStoreService.cfg文件以反映您的单个成员复制副本集
6. 重新启动主作者，以确保它正确重新启动
7. 禁用主作者上的复制代理
8. 在主Author实例上运行预升级维护任务
9. 如有必要，使用WiredTiger将主Mongo实例上的MongoDB升级到版本3.2

升级执行

1. 在主作者上运行就地升级
2. 如果需要​，请更新调度程序或Web模块
3. QA验证升级

如果成功

1. 创建新的6.5作者实例，它们与升级的Mongo实例连接

2. 重建从群集中删除的MongoDB节点

3. 更新DocumentNodeStoreService.cfg文件以反映完整的副本集

4. 重新启动作者实例，一次一个

5. 删除克隆的数据存储。

如果失败（回滚）

1. 重新配置辅助作者实例以连接到克隆的数据存储

2. 关闭升级的作者主实例

3. 关闭升级的Mongo主实例。

4. 开始辅助Mongo实例，其中一个实例作为新的主实例

5. 在辅助作者实例上配置DocumentNodeStoreService.cfg文件，以指向尚未升级的Mongo实例的副本集

6. 开始辅助作者实例

7. 清理升级的作者实例、Mongo节点和数据存储。

TarMK发布场

TarMK发布场

此部分的假定拓扑由两个TarMK发布实例组成，前面是Dispatcher，后面是负载平衡器。 从作者服务器复制到TarMK发布场。

升级执行

1. 在负载平衡器上停止Publish 2实例的通信
2. 在发布2上运行预升级维护
3. 在发布2上运行就地升级
4. 如果需要​，请更新调度程序或Web模块
5. 刷新调度程序缓存
6. QA通过防火墙后的调度程序验证Publish 2
7. 关闭发布2
8. 复制Publish 2实例
9. 开始发布2

如果成功

1. 启用通信以发布2
2. 停止发布1的流量
3. 停止Publish 1实例
4. 将Publish 1实例替换为Publish 2的副本
5. 如果需要​，请更新调度程序或Web模块
6. 刷新Publish 1的调度程序缓存
7. 开始发布1
8. QA通过防火墙后的调度程序验证Publish 1

如果失败（回滚）

1. 创建发布1的副本
2. 将Publish 2实例替换为Publish 1的副本
3. 刷新Publish 2的调度程序缓存
4. 开始发布2
5. QA通过防火墙后的调度程序验证Publish 2
6. 启用通信以发布2

最终升级步骤

1. 启用通信以发布1
2. QA通过公共URL执行最终验证
3. 从“作者”环境启用复制代理
4. 恢复内容创作
5. 执行升级后检查。