Konfigurera nodarkiv och datalager i AEM 6

Introduktion

I Adobe Experience Manager (AEM) kan binära data lagras oberoende av innehållsnoderna. Binära data lagras i ett datalager, medan innehållsnoder lagras i ett nodarkiv.

Både datalager och nodarkiv kan konfigureras med OSGi-konfiguration. Varje OSGi-konfiguration refereras med en beständig identifierare (PID).

Konfigurationssteg

Så här konfigurerar du både nodarkivet och datalagret:

  1. Kopiera den AEM snabbstartsfilen till installationskatalogen.

  2. Skapa en mapp crx-quickstart/install i installationskatalogen.

  3. Konfigurera först nodarkivet genom att skapa en konfigurationsfil med namnet på nodarkivalternativet som du vill använda i crx-quickstart/install katalog.

    Dokumentnodarkivet (som är grunden för AEM MongoMK-implementering) använder filen org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config.

  4. Redigera filen och ange konfigurationsalternativ.

  5. Skapa en konfigurationsfil med PID:t för det datalager som du vill använda. Redigera filen för att ange konfigurationsalternativ.

    OBSERVERA

    Se Konfigurationer för nodarkivet och Konfigurationer för datalager för konfigurationsalternativ.

  6. Börja AEM.

Konfigurationer för nodarkivet

FÖRSIKTIGHET

Nyare versioner av Oak använder ett nytt namnschema och format för OSGi-konfigurationsfiler. Det nya namnschemat kräver att konfigurationsfilen namnges .config och det nya formatet kräver att värden skrivs och dokumenteras här.

Om du uppgraderar från en äldre version av Oak måste du göra en säkerhetskopia av crx-quickstart/installmapp först. Efter uppgraderingen återställer du innehållet i mappen till den uppgraderade installationen och ändrar tillägget för konfigurationsfilerna från .cfg till .config.

Om du läser den här artikeln som förberedelse för en uppgradering från en AEM 5.x installerar du uppgradera dokumentation först.

Segmentnodarkiv

Segmentnodarkivet är grunden för AdobeMK-implementeringen i AEM6. Den använder org.apache.jackrabbit.oak.segment.SegmentNodeStoreService PID för konfiguration.

FÖRSIKTIGHET

PID för segmentnodarkivet har ändrats från org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions av AEM 6 till org.apache.jackrabbit.oak.segment.SegmentNodeStoreService AEM 6.3. Se till att du gör de nödvändiga konfigurationsjusteringarna för att återspegla den här ändringen.

Du kan konfigurera följande alternativ:

  • repository.home: Sökväg till databasstartplats där databasrelaterade data lagras. Segmentfiler lagras som standard under crx-quickstart/segmentstore katalog.

  • tarmk.size: Maximal storlek för ett segment i MB. Standardmaxstorleken är 256 MB.

  • customBlobStore: Booleskt värde som anger att ett anpassat datalager används. Standardvärdet är true för AEM 6.3 och senare versioner. Före AEM 6.3 var standardvärdet false.

Följande är ett exempel org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config fil:

#Path to repo
repository.home="crx-quickstart/repository"

#Max segment size
tarmk.size=I"256"

#Custom data store
customBlobStore=B"true"

Dokumentnodarkiv

Dokumentnodarkivet är grunden för AEM MongoMK-implementering. Den använder org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService* *PID. Följande konfigurationsalternativ är tillgängliga:

  • mongouri: The MongoURI krävs för att ansluta till Mongo-databasen. Standardvärdet är mongodb://localhost:27017

  • db: Namn på Mongo-databasen. Standardvärdet är Oak . However, new AEM 6 installations use **aem-author** som standarddatabasnamn.

  • cache: Cachestorleken i MB. Detta fördelas mellan olika cacheminnen som används i DocumentNodeStore. Standardvärdet är 256

  • changesSize: Storlek i MB på den mappade samling som används i Mongo för cache-lagring av diff-utdata. Standardvärdet är 256

  • customBlobStore: Booleskt värde som anger att ett anpassat datalager kommer att användas. Standardvärdet är false.

Följande är ett exempel org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config fil:

#Mongo server details
mongouri="mongodb://localhost:27017"

#Name of Mongo database to use
db="aem-author"

#Store binaries in custom BlobStore
customBlobStore=B"false"

Konfigurationer för datalager

När du hanterar ett stort antal binära filer bör du använda ett externt datalager i stället för standardnodarkiven för att maximera prestandan.

Om ditt projekt till exempel kräver ett stort antal medieresurser kan du lagra dem i File- eller S3-datalagret så att du kommer åt dem snabbare än att lagra dem direkt i en MongoDB.

Fildatalagret ger bättre prestanda än MongoDB, och säkerhetskopierings- och återställningsåtgärderna i Mongo är också långsammare med ett stort antal resurser.

Information om olika datalager och konfigurationer beskrivs nedan.

OBSERVERA

Om du vill aktivera anpassade datalager måste du se till att customBlobStore är inställd på true i respektive Node Store-konfigurationsfil (segmentnodbutik eller dokumentnodarkiv).

Fildatalager

Detta är genomförandet av FileDataStore finns i Jackrabbit 2. Det är ett sätt att lagra binära data som normala filer i filsystemet. Den använder org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore PID.

Dessa konfigurationsalternativ är tillgängliga:

  • repository.home: Sökväg till databasstartplats där olika databasrelaterade data lagras. Som standard lagras binära filer under crx-quickstart/repository/datastore katalog

  • path: Sökväg till den katalog som filerna ska lagras i. Om det anges har det företräde framför repository.home value

  • minRecordLength: Den minsta storleken i byte för en fil som lagras i datalagret. Binärt innehåll som är mindre än det här värdet infogas.

OBSERVERA

När du använder en NAS för att lagra delade fildatalager bör du endast använda högpresterande enheter för att undvika prestandaproblem.

Amazon S3 - datalager

AEM kan konfigureras för att lagra data i Amazon Simple Storage Service (S3). Den använder org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config PID för konfiguration.

För att aktivera S3-datalagrets funktioner måste ett funktionspaket som innehåller S3 Datastore Connector hämtas och installeras. Gå till Adobe-databas och ladda ned den senaste versionen från 1.10.x-versionerna av funktionspaketet (till exempel com.adobe.granite.oak.s3connector-1.10.0.zip). Dessutom måste du ladda ned och installera det senaste AEM Service Pack som finns på Versionsinformation för AEM 6.5 sida.

OBSERVERA

När du använder AEM med tarMK lagras binärfiler som standard i FileDataStore. Om du vill använda tarMK med S3-datastore måste du börja AEM med crx3tar-nofds runmode, till exempel:

java -jar <aem-jar-file>.jar -r crx3tar-nofds

När du har laddat ned den kan du installera och konfigurera S3 Connector på följande sätt:

  1. Extrahera innehållet i ZIP-filen för funktionspaketet till en tillfällig mapp.

  2. Gå till den tillfälliga mappen och navigera till följande plats:

    jcr_root/libs/system/install
    

    Kopiera allt innehåll från ovanstående plats till <aem-install>/crx-quickstart/install.

  3. Om AEM redan har konfigurerats för att fungera med lagringen tar du bort alla befintliga konfigurationsfiler från <aem-install>/crx-quickstart/installera innan du fortsätter. De filer som behöver tas bort är:

    • For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    • For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Återgå till den tillfälliga platsen där funktionspaketet har extraherats och kopiera innehållet i följande mapp:

    • jcr_root/libs/system/config

    till

    • <aem-install>/crx-quickstart/install

    Kontrollera att du bara kopierar de konfigurationsfiler som behövs för den aktuella konfigurationen. Kopiera org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config -fil.

    OBSERVERA

    Utför ovanstående steg på alla noder i klustret en i taget i en klusterkonfiguration. Se även till att använda samma S3-inställningar för alla noder.

  5. Redigera filen och lägg till de konfigurationsalternativ som krävs för installationen.

  6. Börja AEM.

Uppgradera till en ny version av 1.10.x S3 Connector

Om du behöver uppgradera till en ny version av 1.10.x S3-kontakten (till exempel från 1.10.0 till 1.10.4) följer du dessa steg:

  1. Stoppa AEM.

  2. Navigera till <aem-install>/crx-quickstart/install/15 i AEM installationsmapp och gör en säkerhetskopia av innehållet.

  3. Efter säkerhetskopieringen tar du bort den gamla versionen av S3 Connector och dess beroenden genom att ta bort alla jar-filer i <aem-install>/crx-quickstart/install/15 mapp, till exempel:

    • oak-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    OBSERVERA

    Filnamnen ovan används endast som illustrationer.

  4. Ladda ned den senaste versionen av funktionspaketet 1.10.x från Adobe-databas.

  5. Zippa upp innehållet i en separat mapp och navigera sedan till jcr_root/libs/system/install/15.

  6. Kopiera jar-filerna till <aem-install>/crx-quickstart/install/15 i AEM installationsmapp.

  7. Starta AEM och kontrollera anslutningsfunktionen.

Du kan använda konfigurationsfilen med alternativen nedan.

Alternativ för konfigurationsfil för S3 Connector

OBSERVERA

S3-anslutningen stöder både IAM-användarautentisering och IAM-rollautentisering. Om du vill använda IAM-rollautentisering utelämnar du accessKey och secretKey värden från konfigurationsfilen. S3-kopplingen får då standardvärdet IAM-roll som tilldelats instansen.

Nyckel Beskrivning Standard Krävs
accessKey Åtkomstnyckel-ID för IAM-användaren med åtkomst till bucket. Ja, när IAM-roller inte används.
secretsKey Hemlig åtkomstnyckel för IAM-användaren med åtkomst till bucket. Ja, när IAM-roller inte används.
cacheSize Storleken (i byte) på det lokala cacheminnet. 64 GB Nej.
connectionTimeout Ange väntetiden (i millisekunder) före timeout när anslutningen upprättas första gången. 10000 Nej.
maxCachedBinarySize Binärfiler som är mindre än eller lika med det här värdet (i byte) lagras i minnescachen. 17408 (17 kB) Nej.
maxConnections Ange maximalt antal tillåtna öppna HTTP-anslutningar. 50 Nej.
maxErrorRetry Ange det maximala antalet försök för misslyckade (hämtningsbara) begäranden. 3 Nej.
minRecordLength Den minsta storleken för ett objekt (i byte) som ska lagras i datalagret. 16384 Nej.
path Den lokala sökvägen för AEM. crx-quickstart/repository/datastore Nej.
proxyHost Ange den valfria proxyvärd som klienten ansluter via. Nej.
proxyPort Ange den valfria proxyport som klienten ansluter via. Nej.
s3Bucket Namn på S3-bucket. Ja
s3EndPoint S3 REST API-slutpunkt. Nej.
s3Region Region där bucket finns. Se det här page för mer information. Region där AWS-instansen körs. Nej.
socketTimeout Ställ in väntetiden (i millisekunder) för data som ska överföras via en etablerad, öppen anslutning innan anslutningens timeout inträffar och stängs. 50000 Nej.
stagingPurgeInterval Intervallet (i sekunder) för tömning av slutförda överföringar från mellanlagringscachen. 300 Nej.
stagingRetryInterval Intervallet (i sekunder) för återförsök av misslyckade överföringar. 600 Nej.
stagingSplitPercentage Procentandel av cacheSize som används för att mellanlagra asynkrona överföringar. 10 Nej.
uploadThreads Antalet överföringstrådar som används för asynkrona överföringar. 10 Nej.
writeThreads Antalet samtidiga trådar som används för att skriva via S3 Transfer Manager. 10 Nej.

DataStore-cachelagring

OBSERVERA

DataStore-implementeringar av S3DataStore, CachingFileDataStore och AzureDataStore har stöd för cachelagring av lokala filsystem. The CachingFileDataStore implementeringen är användbar när DataStore är på NFS (Network File System).

När du uppgraderar från en äldre cacheimplementering (före 1.6) är det en skillnad i strukturen för det lokala filsystemets cachekatalog. I den gamla cachestrukturen placerades både de hämtade och de överförda filerna direkt under cachesökvägen. Den nya strukturen delar upp hämtningarna och överföringarna och lagrar dem i två kataloger med namnet upload och download under cachesökväg. Uppgraderingsprocessen bör vara smidig och alla väntande överföringar bör schemaläggas för överföring och alla tidigare hämtade filer i cachen läggs i cachen vid initieringen.

Du kan även uppgradera cacheminnet offline med datastorecacheupgrade kommandot för ekkörning. Mer information om hur du kör kommandot finns i readme för ekkörningsmodulen.

Cachen har en storleksgräns och kan konfigureras med parametern cacheSize.

Nedladdningar

Den lokala cachen kontrolleras för posten för den begärda filen/blobben innan den hämtas från DataStore. När cacheminnet överskrider den konfigurerade gränsen (se cacheSize parameter) när du lägger till en fil i cacheminnet kommer vissa filer att tas bort för att frigöra utrymme.

Asynkron överföring

Cachen stöder asynkrona överföringar till DataStore. Filerna mellanlagras lokalt i cachen (i filsystemet) och ett asynkront jobb börjar överföra filen. Antalet asynkrona överföringar begränsas av mellanlagringscachens storlek. Mellanlagringscachens storlek konfigureras med stagingSplitPercentage parameter. Den här parametern definierar den procentandel av cachestorleken som ska användas för mellanlagringscachen. Dessutom beräknas procentandelen cacheminne som är tillgängligt för nedladdningar som (100 - stagingSplitPercentage) *cacheSize.

De asynkrona överföringarna är flertrådiga och antalet trådar konfigureras med uploadThreads parameter.

Filerna flyttas till huvudcachen för hämtning när överföringen är klar. När storleken på mellanlagringscachen överskrider gränsen överförs filerna synkront till DataStore tills föregående asynkrona överföringar är slutförda och utrymme är igen tillgängligt i mellanlagringscachen. De överförda filerna tas bort från mellanlagringsområdet av ett periodiskt jobb vars intervall har konfigurerats av stagingPurgeInterval parameter.

Misslyckade överföringar (till exempel på grund av nätverksavbrott) placeras i en återförsökskö och försök med jämna mellanrum. Återförsöksintervallet konfigureras med stagingRetryInterval parameter.

Konfigurera icke-binära replikeringar med Amazon S3

Följande steg krävs för att konfigurera binär replikering med S3:

  1. Installera författaren och publicera instanser och se till att de har startats korrekt.

  2. Gå till inställningarna för replikeringsagenten genom att öppna en sida till https://localhost:4502/etc/replication/agents.author/publish.html.

  3. Tryck på Redigera i Inställningar -avsnitt.

  4. Ändra Serialisering textalternativ till Binärt mindre.

  5. Lägg till parametern " binaryless= true" i transport-URI:n. Efter ändringen bör URI:n se ut ungefär så här:

    https://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true

  6. Starta om alla författare- och publiceringsinstanser så att ändringarna börjar gälla.

Skapa ett kluster med S3 och MongoDB

  1. Packa upp CQ-snabbstart med följande kommando:

    java -jar cq-quickstart.jar -unpack

  2. Skapa en mapp i installationskatalogen när AEM har packats upp crx-quickstart/installera.

  3. Skapa dessa två filer i crx-quickstart mapp:

    • org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config

    • org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config

    När filerna har skapats lägger du till konfigurationsalternativen efter behov.

  4. Installera de två paket som krävs för S3-datalagret enligt beskrivningen ovan.

  5. Kontrollera att MongoDB är installerat och att en instans av mongod är igång.

  6. AEM med följande kommando:

    java -Xmx1024m -jar cq-quickstart.jar -r crx3,crx3mongo

  7. Upprepa steg 1 till 4 för den andra AEM instansen.

  8. Starta den andra AEM.

Konfigurera ett delat datalager

  1. Skapa först konfigurationsfilen för datalagret för varje instans som krävs för att dela datalagret:

    • Om du använder en FileDataStore, skapa en fil med namnet org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config och placera den i <aem-install>/crx-quickstart/install mapp.

    • Skapa en fil med namnet o rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config i <aem-install>/crx-quickstart/install enligt ovan.

  2. Ändra konfigurationsfilerna för datalagret på varje instans så att de pekar på samma datalager. Mer information finns i den här artikeln.

  3. Om instansen har klonats från en befintlig server måste du ta bort clusterId den nya instansen genom att använda det senaste ekkörningsverktyget när databasen är offline. Det kommando du behöver köra är:

    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    
    OBSERVERA

    Om en segmentnodbutik har konfigurerats måste databassökvägen anges. Som standard är banan <aem-install-folder>/crx-quickstart/repository/segmentstore. Om en dokumentnodbutik har konfigurerats kan du använda en URI för Mongo-anslutningssträng.

    OBSERVERA

    Du kan hämta verktyget för körning från följande plats:

    https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run/

    Observera att olika versioner av verktyget måste användas beroende på vilken Oak-version du använder i AEM. Kontrollera listan över versionskrav innan du använder verktyget:

    * För ekversioner **1.2.x** använd Oak-run **1.2.12 eller senare**
    * För ekversioner **nyare än ovan** använder du den version av Oak-run som matchar Oak Core i AEM.
    
  4. Validera konfigurationen. För att göra detta måste du söka efter en unik fil som har lagts till i datalagret av varje databas som delar den. Filformatet är repository-[UUID], där UUID är en unik identifierare för varje enskild databas.

    Därför bör en korrekt konfiguration ha så många unika filer som det finns databaser som delar datalagret.

    Filerna lagras på olika sätt beroende på datalagret:

    • För FileDataStore filerna skapas under rotsökvägen för datalagringsmappen.
    • För S3DataStore filerna skapas i den konfigurerade S3-bucket under META mapp.

Azure Data Store

AEM kan konfigureras för att lagra data i Microsoft Azure-lagringstjänst. Den använder org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config PID för konfiguration.

Om du vill aktivera Azure-datalagrets funktioner måste ett funktionspaket som innehåller Azure Connector hämtas och installeras. Gå till Adobe-databas och ladda ned den senaste versionen från 1.6.x-versionerna av funktionspaketet (till exempel com.adobe.granite.oak.azureblobconnector-1.6.3.zip).

OBSERVERA

När du använder AEM med tarMK lagras binärfiler som standard i FileDataStore. Om du vill använda tarMK med Azure DataStore måste du börja AEM med crx3tar-nofds runmode, till exempel:

java -jar <aem-jar-file>.jar -r crx3tar-nofds

När du har hämtat den kan du installera och konfigurera Azure-anslutningen på följande sätt:

  1. Extrahera innehållet i ZIP-filen för funktionspaketet till en tillfällig mapp.

  2. Gå till den tillfälliga mappen och kopiera innehållet i jcr_root/libs/system/install till <aem-install>crx-quickstart/install mapp.

  3. Om AEM redan har konfigurerats för att fungera med lagringen tar du bort alla befintliga konfigurationsfiler från /crx-quickstart/install innan du fortsätter. De filer som behöver tas bort är:

    ForMongoMK:

    org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config

    För tarMK:

    org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

  4. Återgå till den tillfälliga platsen där funktionspaketet har extraherats och kopiera innehållet i jcr_root/libs/system/config till <aem-install>/crx-quickstart/install mapp.

  5. Redigera konfigurationsfilen och lägg till de konfigurationsalternativ som krävs för installationen.

  6. Börja AEM.

Du kan använda konfigurationsfilen med följande alternativ:

  • azureSas="": I version 1.6.3 av kopplingen lades stöd för Azure Shared Access Signature (SAS) till. Om det finns både SAS- och lagringsuppgifter i konfigurationsfilen har SAS prioritet. Mer information om SAS finns i officiell dokumentation. Se till att tecknet '=' föregås av '='.

  • azureBlobEndpoint="": Azure-blobslutpunkten. Till exempel https://<storage-account>.blob.core.windows.net.

  • accessKey="": Lagringskontots namn. Mer information om autentiseringsuppgifter för Microsoft Azure finns i officiell dokumentation.

  • secretsKey="": Lagringsåtkomstnyckeln. Se till att tecknet '=' föregås av '='.

  • container="": Microsoft Azure-lagringsbehållarens namn. Behållaren är en gruppering av en uppsättning blober. Mer information finns i officiell dokumentation.

  • maxConnections="": Antal samtidiga begäranden per åtgärd. Standardvärdet är 1.

  • maxErrorRetry="": Antal återförsök per begäran. Standardvärdet är 3.

  • socketTimeout="": Tidsgränsen i millisekunder som används för begäran. Standardvärdet är 5 minuter.

Förutom inställningarna ovan kan följande inställningar också konfigureras:

  • sökväg: Datalagrets sökväg. Standardvärdet är <aem-install>/repository/datastore.
  • RecordLength: Den minsta storleken för ett objekt som ska lagras i datalagret. Standardvärdet är 16 kB.
  • maxCachedBinarySize: Binärfiler som är mindre än eller lika stora som den här storleken lagras i minnescachen. Storleken anges i byte. Standardvärdet är 17 408 (17 kB).
  • cacheSize: Cachens storlek. Värdet anges i byte. Standardvärdet är 64 GB.
  • hemlighet: Ska endast användas om binär replikering används för konfiguration av delade datalager.
  • stagingSplitPercentage: Procentandel av cachestorleken som är konfigurerad att användas för att mellanlagra asynkrona överföringar. Standardvärdet är 10.
  • uploadThreads: Antalet överförda trådar som används för asynkrona överföringar. Standardvärdet är 10.
  • stagingPurgeInterval: Intervallet i sekunder för tömning av slutförda överföringar från mellanlagringscachen. Standardvärdet är 300 sekunder (5 minuter).
  • stagingRetryInterval: Återförsöksintervallet i sekunder för misslyckade överföringar. Standardvärdet är 600 sekunder (10 minuter).
OBSERVERA

Alla inställningar ska anges mellan citattecken, till exempel:

accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Skräpinsamling för datalager

Datalagrets skräpinsamlingsprocess används för att ta bort oanvända filer i datalagret, vilket frigör värdefullt diskutrymme.

Du kan köra skräpinsamling för datalager genom att:

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

  2. Söker efter RepositoryManagement. När du har hittat Repository Manager MBean klickar du på det för att visa tillgängliga alternativ.

  3. Bläddra till slutet av sidan och klicka på startDataStoreGC(boolesk markOnly) länk.

  4. I följande dialogruta anger du false för markOnly parameter, klicka sedan på Anropa:

    chlimage_1-9

    OBSERVERA

    The markOnly parameter anger om svepfasen för skräpinsamlingen ska köras eller inte.

Skräpinsamling för datalager för ett delat datalager

OBSERVERA

När du utför skräpinsamling i ett klustrat eller delat datalager (med mongo- eller segmentmål) kan loggen visa varningar om att vissa blob-ID inte kan tas bort. Detta beror på att blob-ID:n som tagits bort i en tidigare skräpinsamling felaktigt refereras igen av andra kluster eller delade noder som inte har information om ID-borttagningar. När skräpinsamlingen utförs loggas därför en varning när den försöker ta bort ett ID som redan har tagits bort i den senaste körningen. Det här beteendet påverkar inte prestanda eller funktioner.

OBSERVERA

Om du använder en delad datalagerinställning och datalagrets skräpinsamling är inaktiverad kan rensningen av Lucene-binärfilen plötsligt öka diskutrymmet som används. För att undvika detta måste du inaktivera BlobTracker på alla författare- och publiceringsinstanser enligt följande:

  1. Stoppa AEM.
  2. Lägg till blobTrackSnapshotIntervalInSecs=L"0" -parametern i crx-quickstart/install/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config -fil. Den här parametern kräver Oak 1.12.0, 1.10.2 eller senare.
  3. Starta om AEM.

Med senare versioner av AEM kan skräpinsamlingen i datalagret även köras på datalager som delas av mer än en databas. Gör så här för att kunna köra skräpinsamling i datalager på ett delat datalager:

  1. Se till att alla underhållsuppgifter som konfigurerats för datalagrets skräpinsamling är inaktiverade för alla databasinstanser som delar datalagret.

  2. Kör stegen som anges i Binär skräpinsamling separat den alla databasinstanser som delar datalagret. Tänk dock på att true för markOnly innan du klickar på knappen Anropa:

    chlimage_1-10

  3. När du har slutfört ovanstående procedur på alla instanser kör du skräpinsamlingen för datalagret igen från alla av förekomsterna:

    1. Gå till JMX-konsolen och välj Repository Manager Mbean.
    2. Klicka på Klicka på startDataStoreGC (boolesk markOnly) länk.
    3. I följande dialogruta anger du false för markOnly parametern igen.

    Då sorteras alla filer som hittas med markeringsfasen som använts tidigare och resten som inte används tas bort från datalagret.

På denna sida