文件AEM 6.5使用手冊

升級程式 upgrade-procedure

Last update: Sun Jul 14 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • 主題：

建立對象：

  • undefined
NOTE
由於大部分的Adobe Experience Manager (AEM)升級都會就地執行，因此升級作業需要製作層級的停機時間。 遵循這些最佳實務，您就能將Publish層級停機時間降到最低或完全消除。

升級AEM環境時，您必須考慮升級作者環境或發佈環境之間的方法差異，以將作者和一般使用者的停機時間減至最少。 此頁面概述升級AEM 6.x版本目前所執行AEM拓撲的高階程式。由於程式在製作和發佈層級，以及Mongo和TarMK型部署之間有所不同，因此每個層級和微核心都會列在單獨的區段中。 執行部署時，Adobe建議先升級作者環境、判斷是否成功，然後繼續發佈環境。

TarMK作者階層 tarmk-author-tier

正在啟動拓撲 starting-topology

此區段的假設拓撲包含在TarMK上執行且具有「冷待命」的Author伺服器。 從Author伺服器到TarMK發佈伺服器陣列會進行復寫。 此方法雖然未在此處說明，但也可以用於使用解除安裝的部署。 請確保在作者執行個體上停用復寫代理程式之後，以及在重新啟用它們之前，在新版本上升級或重新建置解除安裝執行個體。

tarmk_starting_topology

升級準備 upgrade-preparation

upgrade-preparation-author

  1. 停止內容製作。

  2. 停止待命執行個體。

  3. 停用作者上的復寫代理。

  4. 執行升級前維護工作。

升級執行 upgrade-execution

execute_upgrade

  1. 執行就地升級。

  2. 視需要更新Dispatcher模組​**。

  3. QA會驗證升級。

  4. 關閉作者執行個體。

如果成功 if-successful

if_successful

  1. 複製升級的執行個體以建立「冷待命」。

  2. 啟動Author例項。

  3. 啟動待命執行個體。

如果失敗（回覆） if-unsuccessful-rollback

回覆

  1. 啟動「冷待命」執行處理作為新的「主要」。

  2. 從冷待命重新建置作者環境。

MongoMK作者叢集 mongomk-author-cluster

正在啟動拓撲 starting-topology-1

此段落的假設拓撲包含至少兩個AEM Author執行個體的MongoMK製作叢集，且支援至少兩個MongoMK資料庫。 所有作者執行個體都會共用資料存放區。 這些步驟應同時適用於S3和檔案資料存放區。 從Author伺服器到TarMK Publish伺服器陣列會進行復寫。

mongo-topology

升級準備 upgrade-preparation-1

mongo-upgrade_prep

  1. 停止內容製作。
  2. 複製資料存放區以進行備份。
  3. 停止所有，但一個AEM Author例項（您的主要作者）除外。
  4. 從復本集（您的主要Mongo執行個體）移除所有MongoDB節點，但一個MongoDB節點除外。
  5. 更新主要作者上的DocumentNodeStoreService.cfg檔案，以反映您的單一成員復本集。
  6. 請重新啟動主要作者，以確保其正確重新啟動。
  7. 停用主要作者上的復寫代理。
  8. 在主要作者執行個體上執行升級前維護工作。
  9. 如有需要，請使用WiredTiger將主要Mongo執行個體上的MongoDB升級至3.2版。

升級執行 Upgrade-execution-1

mongo-execution

  1. 在主要作者上執行就地升級。
  2. 視需要更新Dispatcher或Web模組​**。
  3. QA會驗證升級。

如果成功 if-successful-1

mongo-secondaries

  1. 建立新的6.5編寫執行個體，連線至升級的Mongo執行個體。

  2. 重建從叢集移除的MongoDB節點。

  3. 更新DocumentNodeStoreService.cfg檔案以反映完整的復本集。

  4. 一次一個重新啟動作者執行個體。

  5. 移除複製的資料存放區。

如果失敗（回覆） if-unsuccessful-rollback-2

mongo-rollback

  1. 重新設定次要Author例項，以連線至複製的資料存放區。

  2. 關閉升級的作者主要執行個體。

  3. 關閉升級的Mongo主要執行個體。

  4. 啟動次要Mongo執行個體，並將其中一個執行個體作為新的主要執行個體。

  5. 設定次要Author執行個體上的DocumentNodeStoreService.cfg檔案，以指向尚未升級之Mongo執行個體的復本集。

  6. 啟動次要Author例項。

  7. 清理升級的作者執行個體、Mongo節點和資料存放區。

TarMK Publish農場 tarmk-publish-farm

TarMK Publish農場 tarmk-publish-farm-1

此區段的假設拓撲包含兩個TarMK發佈執行個體，由Dispatcher前導，而該前導又是負載平衡器。 從Author伺服器到TarMK Publish陣列會進行復寫。

tarmk-pub-farmv5

升級執行 upgrade-execution-2

upgrade-publish2

  1. 在負載平衡器處停止到Publish 2執行個體的流量。
  2. 在Publish 2上執行升級前維護。
  3. 在Publish 2上執行就地升級。
  4. 視需要更新Dispatcher或Web模組​**。
  5. 排清Dispatcher快取。
  6. QA會透過Dispatcher在防火牆後面驗證Publish 2。
  7. 關閉Publish 2。
  8. 複製Publish 2執行個體。
  9. 啟動Publish 2.

如果成功 if-successful-2

upgrade-publish1

  1. 啟用Publish 2的流量。
  2. 停止與Publish 1的流量。
  3. 停止Publish 1執行個體。
  4. 將Publish 1執行個體取代為Publish 2的復本。
  5. 視需要更新Dispatcher或Web模組​**。
  6. 清除Publish 1的Dispatcher快取。
  7. 啟動Publish 1.
  8. QA會透過Dispatcher在防火牆後面驗證Publish 1。

如果失敗（回覆） if-unsuccessful-rollback-1

pub_rollback

  1. 建立Publish 1的復本。
  2. 將Publish 2執行個體取代為Publish 1的復本。
  3. 清除Publish 2的Dispatcher快取。
  4. 啟動Publish 2.
  5. QA會透過Dispatcher在防火牆後面驗證Publish 2。
  6. 啟用Publish 2的流量。

最終升級步驟 final-upgrade-steps

  1. 啟用Publish 1的流量。
  2. QA會從公用URL執行最終驗證。
  3. 從製作環境啟用復寫代理程式。
  4. 繼續內容製作。
  5. 執行升級後檢查。

最終

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