Underhållsaktiviteter före uppgraderingen pre-upgrade-maintenance-tasks

Innan du påbörjar uppgraderingen är det viktigt att du följer dessa underhållsåtgärder för att vara säker på att systemet är klart och kan återställas om det skulle uppstå problem:

Se till att det finns tillräckligt med diskutrymme ensure-sufficient-disk-space

När du utför uppgraderingen måste du utföra en databasmigrering, förutom innehålls- och koduppgraderingsaktiviteterna. Migreringen skapar en kopia av databasen i det nya segmenttjärformatet. Därför behöver du tillräckligt med diskutrymme för att behålla en andra, eventuellt större, version av databasen.

Helt AEM fully-back-up-aem

AEM bör säkerhetskopieras fullständigt innan uppgraderingen påbörjas. Säkerhetskopiera databasen, programinstallationen, datalagret och Mongo-instanserna om tillämpligt. Mer information om säkerhetskopiering och återställning av en AEM finns i Säkerhetskopiering och återställning.

Säkerhetskopiera ändringar i /etc backup-changes-etc

Uppgraderingsprocessen gör det möjligt att underhålla och sammanfoga befintligt innehåll och befintliga konfigurationer från /apps och /libs sökvägar i databasen. För ändringar i /etc sökväg, inklusive Context Hub-konfigurationer, är det ofta nödvändigt att tillämpa dessa ändringar igen efter uppgraderingen. Under uppgraderingen görs en säkerhetskopia av alla ändringar som inte kan sammanfogas under /varrekommenderar vi att du säkerhetskopierar dessa ändringar manuellt innan du påbörjar uppgraderingen.

Generera filen quickstart.properties generate-quickstart-properties

När du börjar AEM från filen jar quickstart.properties filen skapas under crx-quickstart/conf. Om AEM bara har startats med det tidigare startskriptet kommer den här filen inte att finnas och uppgraderingen misslyckas. Kontrollera om filen finns och starta om AEM från filen jar om den inte finns.

Konfigurera rensning av arbetsflöde och granskningslogg configure-wf-audit-purging

The WorkflowPurgeTask och com.day.cq.audit.impl.AuditLogMaintenanceTask uppgifter kräver separata OSGi-konfigurationer och fungerar inte utan dem. Om de inte fungerar när en uppgift körs före uppgraderingen är det mest troligt att konfigurationer saknas. Se därför till att du lägger till OSGi-konfigurationer för dessa uppgifter eller tar bort dem helt och hållet från listan över uppgifter som ska optimeras före uppgraderingen om du inte vill köra dem. Dokumentation om hur du konfigurerar rensningsåtgärder för arbetsflöden finns på Administrera arbetsflödesinstanser och konfigurationen av underhållsaktiviteten för granskningsloggen finns på Granskningslogghantering i AEM 6.

Information om rensning av arbetsflödes- och granskningslogg på CQ 5.6 samt rensning av granskningslogg på AEM 6.0 finns i Rensa arbetsflödes- och granskningsnoder.

Installera, konfigurera och köra uppgifter före uppgradering install-configure-run-pre-upgrade-tasks

På grund av den nivå av anpassning som AEM tillåter, följer miljöer vanligtvis inte ett enhetligt sätt att utföra uppgraderingar. Detta gör det svårt att skapa en standardiserad uppgraderingsprocedur.

I tidigare versioner var det också svårt för AEM uppgraderingar som stoppats eller som inte återställts på ett säkert sätt. Detta ledde till situationer där det var nödvändigt att starta om hela uppgraderingsförfarandet eller där felaktiga uppgraderingar utfördes utan att några varningar utlöstes.

För att åtgärda dessa problem har Adobe lagt till flera förbättringar i uppgraderingsprocessen, vilket gör den mer flexibel och användarvänlig. Underhållsuppgifter före uppgradering som tidigare skulle utföras manuellt optimeras och automatiseras. Rapporter efter uppgraderingen har lagts till så att processen kan granskas i sin helhet i hopp om att problemen blir enklare.

Underhållsuppgifter före uppgradering sprids för närvarande över olika gränssnitt som delvis eller helt utförs manuellt. Den underhållsoptimering före uppgradering som introducerades i AEM 6.3 möjliggör ett enhetligt sätt att utlösa dessa uppgifter och kunna inspektera deras resultat vid behov.

Alla uppgifter som ingår i det föruppgraderade optimeringssteget är kompatibla med alla versioner från och med AEM 6.0.

Så här konfigurerar du how-to-set-it-up

I AEM 6.3 och senare finns underhållsoptimeringen i snabbstartsbehållaren. Om du uppgraderar från en äldre version av AEM 6 görs de tillgängliga via separata paket som du kan hämta från pakethanteraren.

Paketen finns på följande platser:

Så här använder du den how-to-use-it

The PreUpgradeTasksMBean OSGI-komponenten levereras förkonfigurerad med en lista över föruppgraderade underhållsåtgärder som kan köras alla samtidigt. Du kan konfigurera uppgifterna genom att följa proceduren nedan:

Uppgiftslistan varierar beroende på vilket körningsläge som används för att starta instansen. Nedan visas en beskrivning av det körläge som varje underhållsåtgärd är avsedd för.

Standardkonfiguration för hälsokontroller före uppgradering default-configuration-of-the-pre-upgrade-health-checks

The PreUpgradeTasksMBeanImpl OSGI-komponenten levereras förkonfigurerad med en lista med föruppgraderingstaggar för hälsokontroll som ska köras när runAllPreUpgradeHealthChecks metoden anropas:

Listan kan redigeras. Du kan använda plustecknet (+) och minus (-) förutom taggarna för att lägga till fler anpassade taggar eller ta bort standardtaggar.

MBean-metoder

Den hanterade böldfunktionen är tillgänglig med JMX Console.

Du kan komma åt MBeans genom att:

Nedan visas en lista med alla tillgängliga metoder som PreUpgradeTasksMBeanImpl exponeras:

Inaktivera anpassade inloggningsmoduler disable-custom-login-modules

Skräddarsytt sätt LoginModules har konfigurerats för autentisering på databasnivå och har ändrats i Apache Oak.

I AEM versioner som använde CRX2-konfiguration placerades i repository.xml filen, medan den från och med AEM 6 görs i Apache Felix JAAS Configuration Factory-tjänsten via webbkonsolen.

Alla befintliga konfigurationer måste därför inaktiveras och återskapas för Apache Oak efter uppgraderingen.

Inaktivera anpassade moduler som definierats i JAAS-konfigurationen för repository.xmlmåste du ändra konfigurationen för att kunna använda standardinställningarna LoginModule, som i det här exemplet:

<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>

Ta bort uppdateringar från katalogen /install remove-updates-install-directory

Ta bort alla servicepaket, funktionspaket eller snabbkorrigeringar som har distribuerats via crx-quickstart/install på det lokala filsystemet. Detta förhindrar oavsiktlig installation av gamla snabbkorrigeringar och servicepaket ovanpå den nya AEM när uppdateringen har slutförts.

Stoppa alla väntelägesförekomster i kallt läge stop-tarmk-coldstandby-instance

Om du använder kallstart för TjäraMK ska du stoppa alla kalliga standby-instanser. Detta garanterar ett effektivt sätt att komma tillbaka online om det uppstår problem i uppgraderingen. När uppgraderingen har slutförts måste alla instanser av kallstart återskapas från de uppgraderade primära instanserna.

Inaktivera anpassade schemalagda jobb disable-custom-scheduled-jobs

Inaktivera alla schemalagda OSGi-jobb som ingår i programkoden.

Kör rensning av offlineredigering execute-offline-revision-cleanup

Om du använder tarMK bör du köra Revision Cleanup offline innan du uppgraderar. Detta gör att migreringen av databasen och efterföljande uppgraderingsuppgifter går mycket snabbare och säkerställer att rensning av onlineändringar kan utföras korrekt när uppgraderingen har slutförts. Mer information om hur du kör funktionen för borttagning av offlinerevision finns i Utför rensning av offlineredigering.

Kör skräpinsamling för datastore execute-datastore-garbage-collection

När du har kört revisionsrensning på CRX3-instanser bör du köra Datastore-skräpinsamlingen för att ta bort alla blobbar som inte refereras i datalagret. Instruktioner finns i dokumentationen om Skräpinsamling för datalager.

Ta bort användare som kan tyda på en uppgradering delete-users-that-might-hinder-the-upgrade

Det finns exceptionella fall när tjänstanvändare kan få äldre AEM som felaktigt taggade som vanliga användare.

Om detta inträffar kommer uppgraderingen att misslyckas med ett meddelande som detta:

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.

Se till att du gör följande för att lösa problemet:

Se till att du gör följande för att lösa problemet:

Uppgradera databasschemat om det behövs upgrade-the-database-schema-if-needed

Vanligtvis tar den underliggande Apache Oak-stacken AEM använder för beständighet hand om att uppgradera databasschemat vid behov.

Det kan dock inträffa när schemat inte kan uppgraderas automatiskt. Detta är oftast miljöer med hög säkerhet där databasen körs under en användare med mycket begränsade behörigheter. Om detta händer kommer AEM att fortsätta använda det gamla schemat.

För att förhindra att detta händer måste du uppgradera schemat genom att följa nedanstående procedur:

Rotera loggfiler rotate-log-files

Vi rekommenderar att du arkiverar dina aktuella loggfiler innan du påbörjar uppgraderingen. Detta gör det enklare att övervaka och söka igenom loggfilerna under och efter uppgraderingen för att identifiera och lösa eventuella problem som kan uppstå.