升級前維護任務 pre-upgrade-maintenance-tasks
在開始升級之前,請務必遵循這些維護任務,以確保系統準備就緒,並可在發生問題時回覆:
確保有足夠的磁碟空間 ensure-sufficient-disk-space
執行升級時,除了內容和程式碼升級活動外,還必須執行存放庫移轉。 移轉作業會以新的Segment Tar格式建立存放庫復本。 因此,您需要足夠的磁碟空間,以保留儲存庫的第二個(可能更大)版本。
完全備份AEM fully-back-up-aem
在開始升級之前,應該先完整備份AEM。 請務必備份存放庫、應用程式安裝、資料存放區和Mongo執行個體(如適用)。 如需有關備份與還原AEM執行個體的詳細資訊,請參閱備份與還原。
將變更備份至/etc backup-changes-etc
升級程式在維護及合併存放庫中/apps
及/libs
路徑下的現有內容與設定方面做得很好。 對於/etc
路徑的變更(包括Context Hub設定),通常需要在升級後重新套用這些變更。 雖然升級會備份任何無法在/var
下合併的變更,但Adobe建議您在開始升級前手動備份這些變更。
產生quickstart.properties檔案 generate-quickstart-properties
從jar檔案啟動AEM時,會在crx-quickstart/conf
下產生quickstart.properties
檔案。 如果AEM過去僅以啟動指令碼啟動,則此檔案不存在,且升級失敗。 請確定檢查此檔案是否存在,如果不存在,請從jar檔案重新啟動AEM。
設定工作流程和稽核記錄清除 configure-wf-audit-purging
WorkflowPurgeTask
和com.day.cq.audit.impl.AuditLogMaintenanceTask
任務需要單獨的OSGi設定,沒有它們就無法運作。 如果它們在升級前工作執行期間失敗,遺失設定是最可能的原因。 因此,如果您不想執行OSGi設定,請務必為這些工作新增OSGi設定,或將其從升級前最佳化工作清單中完全移除。 您可以在管理工作流程執行個體找到設定工作流程清除工作的檔案,也可以在AEM 6🔗中的稽核記錄維護,找到稽核記錄維護工作設定。
如需CQ 5.6的工作流程與稽核記錄清除,以及AEM 6.0的稽核記錄清除,請參閱清除工作流程與稽核節點。
安裝、設定及執行升級前工作 install-configure-run-pre-upgrade-tasks
由於AEM允許的自訂等級,環境通常不遵循統一的執行升級方式。 因此,建立標準化的升級程式將是一個困難的過程。
在舊版中,已停止或無法安全繼續的AEM升級也很難進行。 此問題會導致需要重新啟動完整升級程式的情況,或執行有缺陷的升級而不會觸發任何警告的情況。
為了解決這些問題,Adobe在升級程式中新增了數個增強功能,使其更具復原力且更方便使用。 升級前必須手動執行的維護工作已最佳化並自動化。 此外,已新增升級後報告,以便可以完全審查程式,希望更容易發現任何問題。
升級前的維護工作目前分散在手動執行部分或全部的各種介面中。 AEM 6.3中推出的升級前維護最佳化可讓您以統一方式觸發這些任務,並可依需求檢查結果。
升級前最佳化步驟中包含的所有工作與AEM 6.0以後的所有版本都相容。
如何設定 how-to-set-it-up
在AEM 6.3和更新版本中,升級前維護最佳化任務包含在快速入門jar中。
使用方式 how-to-use-it
PreUpgradeTasksMBean
OSGI元件已預先設定可一次執行所有升級前維護工作的清單。 您可以依照以下程式來設定這些工作:
-
瀏覽至 https://serveraddress:serverport/system/console/configMgr 以移至Web主控台
-
搜尋「preupgradetasks」,然後按一下第一個相符的元件。 元件的完整名稱是
com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
-
修改必須執行的維護工作清單,如下所示:
工作清單會因用來啟動執行個體的執行模式而有所不同。 以下說明每個維護任務所針對的執行模式。
DataStoreGarbageCollectionTask
會呼叫具有標籤和清除階段(若已使用)的資料存放區記憶體回收作業。 對於使用共用資料存放區的部署,請務必正確重新設定或準備執行個體,以避免刪除其他執行個體參考的專案。 此程式可能需要在觸發此升級前工作之前,在所有執行個體上手動執行標籤階段。升級前健康狀態檢查的預設設定 default-configuration-of-the-pre-upgrade-health-checks
PreUpgradeTasksMBeanImpl
OSGI元件已預先設定在呼叫runAllPreUpgradeHealthChecks
方法時要執行的升級前健康情況檢查標籤清單:
-
system - granite維護狀況檢查所使用的標籤
-
升級前 — 可新增到升級前可設定執行之所有健康狀態檢查的自訂標籤
清單可編輯。 除了標籤之外,您可以使用加號 (+) 和減號 (-) 按鈕來新增更多自訂標籤,或移除預設標籤。
MBean方法
可以使用JMX主控台存取受管理Bean功能。
存取MBean的方法有:
-
前往位於 https://serveraddress:serverport/system/console/jmx 的JMX主控台
-
搜尋 PreUpgradeTasks 並按一下結果
-
從 作業 區段中選取任何方法,並在下列視窗中選取 叫用。
以下為PreUpgradeTasksMBeanImpl
公開的所有可用方法清單:
- JMX主控台
- 連線到JMX的任何外部應用程式
- cURL
停用自訂登入模組 disable-custom-login-modules
在存放庫層級設定用於驗證的自訂LoginModules
的方式在Apache Oak中發生了根本性變化。
在使用CRX2設定的AEM版本中,該設定置於repository.xml
檔案中,而從AEM 6開始,則是透過Web主控台在Apache Felix JAAS Configuration Factory服務中完成。
因此,在升級後,必須停用任何現有的設定,並為Apache Oak重新建立。
若要停用repository.xml
的JAAS組態中定義的自訂模組,您必須編輯組態以使用預設LoginModule
,如下列範例所示:
<Security >
....
<!--
Use LoginModule authenticating against repository itself
-->
<LoginModule class = "com.day.crx.core.CRXLoginModule" >
<param name = "anonymousId" value = "anonymous" />
<param name = "adminId" value ="admin" />
<param name = "disableNTLMAuth" value = "true" />
<param name = "tokenExpiration" value = "43200000" />
<!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
-->
</LoginModule >
</ Security>
從/install目錄移除更新 remove-updates-install-directory
移除任何透過本機檔案系統上的crx-quickstart/install
目錄部署的Service Pack、Feature Pack或Hotfix。 如此可防止在更新完成後,在新AEM版本之上意外安裝舊的Hotfix和Service Pack。
停止任何冷待命執行個體 stop-tarmk-coldstandby-instance
如果使用TarMK冷待命,請停止任何冷待命執行個體。 這麼做可確保在升級過程中發生問題時,能以有效率的方式重新上線。 成功完成升級後,必須從升級的主要執行個體重建冷待命執行個體。
停用自訂排程工作 disable-custom-scheduled-jobs
停用應用程式程式碼中包含的任何OSGi排程工作。
執行離線修訂清除 execute-offline-revision-cleanup
如果使用TarMK,您應在升級前執行離線修訂清除。 如此一來,存放庫移轉步驟和後續升級工作執行速度會大幅加快,有助於確保在升級完成後,線上修訂清除可以成功執行。 如需有關執行離線修訂清除的資訊,請參閱執行離線修訂清除。
執行資料存放區記憶體回收 execute-datastore-garbage-collection
在CRX3執行個體上執行修訂清除後,您應該執行資料存放區記憶體回收,以移除資料存放區中所有未參考的blob。 如需指示,請參閱有關資料存放區記憶體回收的檔案。
視需要升級資料庫綱要 upgrade-the-database-schema-if-needed
AEM用於持續性的基礎Apache Oak棧疊通常會在需要時負責升級資料庫架構。
但是,當結構描述無法自動升級時可能會出現這種情況。 這類情況主要是高安全性的環境,其中資料庫是在許可權有限的使用者下執行。 如果發生這種情況,AEM會繼續使用舊的結構描述。
若要避免發生這類情況,請執行以下動作來升級結構:
-
關閉必須升級的AEM執行個體。
-
升級資料庫結構描述。 請參閱資料庫型別的檔案,瞭解需要什麼工具才能取得結果。
如需Oak如何處理結構描述升級的詳細資訊,請參閱Apache網站上的此頁面。
-
繼續升級AEM。
刪除可能阻礙升級的使用者 delete-users-that-might-hinder-the-upgrade
- 您正從AEM 6.3之前的AEM版本升級
- 在升級期間,您會遇到以下提及的任何錯誤。
在特殊情況下,服務使用者可能會在舊版AEM中被錯誤標籤為一般使用者。
如果發生這種情況,升級會失敗,並出現以下訊息:
ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.
若要解決此問題,請務必執行下列動作:
-
將執行個體與生產流量分離
-
建立一或多個造成問題的使用者的備份。 您可以透過「封裝管理員」來執行此工作。 如需詳細資訊,請參閱如何使用封裝。
-
刪除一或多個造成問題的使用者。 以下是可能屬於此類別的使用者清單:
dynamic-media-replication
communities-ugc-writer
communities-utility-reader
communities-user-admin
oauthservice
sling-scripting
旋轉記錄檔 rotate-log-files
Adobe建議在開始升級之前,先封存目前的記錄檔。 如此一來,在升級期間和升級之後,您就可以更輕鬆地監視和掃描記錄檔,以識別並解決任何可能發生的問題。