升級前維護任務 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時, quickstart.properties
檔案產生於 crx-quickstart/conf
. 如果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元件預先設定了可一次執行所有升級前維護工作的清單。 您可以依照以下程式來設定這些工作:
-
瀏覽至,前往Web主控台 https://serveraddress:serverport/system/console/configMgr
-
搜尋"preupgradetasks「」,然後按一下第一個相符的元件。 元件的完整名稱為
com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
-
修改必須執行的維護工作清單,如下所示:
工作清單會因用來啟動執行個體的執行模式而有所不同。 以下說明每個維護任務所針對的執行模式。
DataStoreGarbageCollectionTask
呼叫具有標籤和掃描階段(若已使用)的資料存放區記憶體回收作業。 對於使用共用資料存放區的部署,請務必正確重新設定或準備執行個體,以避免刪除其他執行個體參考的專案。 此程式可能需要在觸發此升級前工作之前,在所有執行個體上手動執行標籤階段。升級前健康狀態檢查的預設設定 default-configuration-of-the-pre-upgrade-health-checks
此 PreUpgradeTasksMBeanImpl
OSGI元件預先設定了升級前健康情況檢查標籤的清單,以便 runAllPreUpgradeHealthChecks
方法稱為:
-
系統 - granite維護狀況檢查所使用的標籤
-
升級前 — 自訂標籤,可新增至升級前可設定為執行的所有健康狀態檢查中
清單可編輯。 您可以使用加號 (+) 和減號 (-) 標籤以外的按鈕,以新增更多自訂標籤或移除預設標籤。
MBean方法
可使用以下專案來存取受管理的Bean功能 JMX主控台.
存取MBean的方法有:
-
前往位於的JMX控制檯 https://serveraddress:serverport/system/console/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重新建立。
若要停用的JAAS組態中定義的自訂模組 repository.xml
,您必須編輯設定以使用預設值 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
移除透過部署的任何Service Pack、Feature Pack或Hotfix。 crx-quickstart/install
目錄。 如此可防止在更新完成後,在新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建議在開始升級之前,先封存目前的記錄檔。 如此一來,在升級期間和升級之後,您就可以更輕鬆地監視和掃描記錄檔,以識別並解決任何可能發生的問題。