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, utöver content and code upgrade-aktiviteterna. 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 som gjorts i /etc sökväg, inklusive Context Hub-konfigurationer, är det ofta nödvändigt att återanvända dessa ändringar efter uppgraderingen. När uppgraderingen gör en säkerhetskopia av alla ändringar som den inte kan sammanfogas under /varrekommenderar Adobe 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 genereras under crx-quickstart/conf. Om AEM bara har startats med det tidigare startskriptet finns inte den här filen 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 kan inte fungera 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.

Mer information om rensning av arbetsflödes- och granskningslogg i CQ 5.6 och rensning av granskningslogg i 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. Därför ä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å en omstart av det fullständiga uppgraderingsförfarandet var nödvändig 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.

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:

  1. Gå till webbkonsolen genom att gå till https://serveraddress:serverport/system/console/configMgr

  2. Sök efter "föruppgraderingsuppgifter" och klicka sedan på den första matchande komponenten. Komponentens fullständiga namn är com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Ändra listan över underhållsaktiviteter som måste köras enligt nedan:

    1487758925984

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.

Uppgift
Körningsläge
Anteckningar
TarIndexMergeTask
crx2
DataStoreGarbageCollectionTask
crx2
Kör mark och svepning. Ta bort det här steget och kör för delade datalager
förbered instanser manuellt eller korrekt före körning.
ConsistencyCheckTask
crx2
WorkflowPurgeTask
crx2/crx3
Du måste konfigurera OSGi för rensningskonfiguration för arbetsflöde för Adobe Granite innan du kör.
GenerateBundlesListFileTask
crx2/crx3
RevisionCleanupTask
crx3
Om du använder TjäraMK-instanser AEM 6.0 till 6.2 ska du manuellt köra Revision Cleanup offline i stället.
com.day.cq.audit.impl.AuditLogMaintenanceTask
crx3
Du måste konfigurera OSGi-konfigurationen för rensning av granskningslogg innan du kör.
CAUTION
The DataStoreGarbageCollectionTask anropar en DataStore-skräpinsamlingsåtgärd med markerings- och svepfasen om en sådan används. För distributioner som använder ett delat datalager måste du antingen konfigurera om det korrekt eller förbereda instansen för att undvika att objekt som refereras av en annan instans tas bort. Den här processen kan kräva att markeringsfasen körs manuellt på alla instanser innan den här föruppgraderingsaktiviteten aktiveras.

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:

  • system - den tagg som används av hälsokontrollerna för granitunderhåll

  • föruppgradering - en anpassad tagg som kan läggas till i alla hälsokontroller som du kan ställa in att köra före en uppgradering

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:

  1. Gå till JMX-konsolen på https://serveraddress:serverport/system/console/jmx

  2. Sök efter PreUpgradeTasks och klicka på resultatet

  3. Välj en metod i Operationer avsnitt och markera Anropa i följande fönster.

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

Metodnamn
Typ
Beskrivning
getAvailablePreUpgradeTasksNames()
INFO
Visar en lista med tillgängliga namn på underhållsaktiviteter före uppgradering.
getAvailablePreUpgradeHealthChecksTagNames()
INFO
Visar en lista med taggar för hälsokontroller som är före uppgraderingen.
runAllPreUpgradeTasks()
ÅTGÄRD
Kör alla underhållsaktiviteter som är före uppgraderingen i listan.
runPreUpgradeTask(preUpgradeTaskName)
ÅTGÄRD
Kör underhållsaktiviteten före uppgradering med det namn som anges som parameter.
isRunAllPreUpgradeTaskRunning()
ACTION_INFO
Kontrollerar om runAllPreUpgradeTasksmaintenance aktiviteten körs.
getAnyPreUpgradeTaskRunning()
ACTION_INFO
Kontrollerar om någon underhållsuppgift som har slutförts före uppgraderingen körs och
returnerar en array som innehåller namnen på de uppgifter som körs.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName)
ÅTGÄRD
Visar den exakta körningstiden för underhållsaktiviteten före uppgradering med det namn som anges som parameter.
getPreUpgradeTaskLastRunState(preUpgradeTaskName)
ÅTGÄRD
Visar det senaste körningstillståndet för underhållsaktiviteten före uppgradering med det namn som anges som parameter.
runAllPreUpgradeHealthChecks(shutDownOnSuccess)
ÅTGÄRD

Kör alla föruppgraderingskontroller och sparar statusen i en fil med namnet preUpgradeHCStatus.properties som är i den slingrande hemvägen. Om shutDownOnSuccess parametern är inställd på trueAEM stängs av, men bara om alla hälsokontroller före uppgraderingen har statusen OK.

Egenskapsfilen används som en förutsättning för framtida uppgraderingar
och uppgraderingsprocessen avbryts om hälsokontrollen före uppgraderingen görs
körningen misslyckades. Om du vill ignorera resultatet av föruppgraderingen
hälsokontroller och starta uppgraderingen ändå kan du ta bort filen.

detectUsageOfUnavailableAPI(aemVersion)
ÅTGÄRD
Visar alla importerade paket som inte längre är uppfyllda när
uppgradera till den angivna AEM. AEM måste vara
anges som parameter.
NOTE
MBean-metoderna kan anropas via:
  • JMX-konsolen
  • Alla externa program som ansluter till JMX
  • cURL

Inaktivera anpassade inloggningsmoduler disable-custom-login-modules

NOTE
Det här steget krävs bara om du uppgraderar från en version av AEM 5. Den kan hoppas över helt och hållet för uppgraderingar från äldre AEM 6-versioner.

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 redigera konfigurationen för att kunna använda standardinställningen LoginModule, som i följande exempel:

<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>
NOTE
Mer information finns i Autentisering med modulen för extern inloggning.
Ett exempel på LoginModule konfiguration i AEM 6, se Konfigurera LDAP med AEM 6.

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

NOTE
Ta endast bort paket från katalogen crx-quickstart/install när AEM stängts. Det här steget är ett av de sista innan du startar uppgraderingsproceduren på plats.

Ta bort alla servicepaket, funktionspaket eller snabbkorrigeringar som distribuerats via crx-quickstart/install på det lokala filsystemet. På så sätt förhindras oavsiktlig installation av gamla snabbkorrigeringar och servicepaket ovanpå den nya AEM-versionen 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 återansluta till Internet om det uppstår problem i uppgraderingen. När uppgraderingen har slutförts måste instanserna i kallt vänteläge å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

NOTE
Detta steg är endast nödvändigt för bensinanläggningar

Om du använder tarMK bör du köra Revision Cleanup offline innan du uppgraderar. Detta gör att databasmigreringssteget och efterföljande uppgraderingsuppgifter körs mycket snabbare och hjälper till att säkerställa 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

NOTE
Det här steget är bara nödvändigt för instanser som kör crx3

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

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

Vanligtvis tar den underliggande Apache Oak-stacken som AEM använder för beständighet hand om att uppgradera databasschemat, om det behövs.

Det kan dock inträffa när schemat inte kan uppgraderas automatiskt. Sådana fall är oftast högsäkerhetsmiljöer där databasen körs under en användare med begränsad behörighet. Om en sådan situation inträffar fortsätter AEM att använda det gamla schemat.

Om du vill förhindra att ett sådant scenario inträffar uppgraderar du schemat genom att göra följande:

  1. Stäng den AEM som måste uppgraderas.

  2. Uppgradera databasschemat. Läs dokumentationen för din databastyp för att se vilka verktyg som krävs för att uppnå resultatet.

    Mer information om hur Oak hanterar schemauppgraderingar finns i den här sidan på Apache-webbplatsen.

  3. Fortsätt med AEM.

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

NOTE
Underhållsuppgifterna är bara nödvändiga om:
  • Du uppgraderar från AEM versioner äldre än AEM 6.3
  • Du stöter på något av de fel som nämns nedan under uppgraderingen.

Det finns exceptionella fall när tjänstanvändare kan hamna i en äldre AEM version som felaktigt taggats som vanliga användare.

Om en sådan situation uppstår misslyckas uppgraderingen med ett meddelande som följande:

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 undvika problemet:

  1. Frigör instansen från produktionstrafiken

  2. Skapa en säkerhetskopia av en eller flera användare som orsakar problemet. Du kan utföra den här uppgiften med Pakethanteraren. Mer information finns i Arbeta med paket.

  3. Ta bort en eller flera användare som orsakar problemet. Nedan finns en lista över användare som kan ingå i den här kategorin:

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

Rotera loggfiler rotate-log-files

Adobe rekommenderar att du arkiverar dina aktuella loggfiler innan du påbörjar uppgraderingen. På så sätt blir det enklare att övervaka och skanna loggfilerna under och efter uppgraderingen för att identifiera och lösa eventuella problem som kan uppstå.

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