Konfigurera nodarkiv och datalager i AEM 6 configuring-node-stores-and-data-stores-in-aem

Introduktion introduction

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

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.

    note note
    NOTE
    Se Konfigurationer för nodarkivet och Konfigurationer för datalager för konfigurationsalternativ.
  6. Börja AEM.

Konfigurationer för nodarkivet node-store-configurations

CAUTION
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 inför en uppgradering från en AEM 5.x installerar du uppgradera dokumentation först.

Segmentnodarkiv segment-node-store

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

CAUTION
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: Ett 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 document-node-store

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: MongoURI krävs för att ansluta till Mongo-databasen. Standardvärdet är mongodb://localhost:27017

  • db: Namnet 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å en kopplad samling som används i Mongo för cache-lagring av diff-utdata. Standardvärdet är 256

  • customBlobStore: Ett booleskt värde som anger att ett anpassat datalager används. 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 data-store-configurations

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 många medieresurser och du lagrar dem i File- eller S3-datalagret blir det snabbare att komma åt dem ä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.

NOTE
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 file-data-store

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.

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

Amazon S3 - datalager amazon-s-data-store

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.

NOTE
AEM 6.5 har stöd för datalagring i Amazon S3, men det finns inte stöd för att lagra data på andra plattformar, vars leverantörer kan ha egna implementeringar av Amazon S3-API:er.

Om du vill aktivera S3-datalagringsfunktionen måste ett funktionspaket som innehåller S3 Datastore Connector hämtas och installeras. Gå till Adobe Repository 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). Du måste även hämta och installera det senaste AEM Service Pack som finns på Versionsinformation för AEM 6.5 sida.

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

    code language-xml
    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 måste 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. För både ett dedikerat datalager och ett delat datalager kopierar org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config -fil.

    note note
    NOTE
    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 upgrading-to-a-new-version-of-the-s-connector

Så här uppgraderar du till en ny version av 1.10.x S3-kontakten (till exempel från 1.10.0 till 1.10.4):

  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 till exempel:

    • oak-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    note note
    NOTE
    Filnamnen ovan används endast som illustrationer.
  4. Ladda ned den senaste versionen av funktionspaketet 1.10.x från Adobe Repository.

  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 s3-connector-configuration-file-options

NOTE
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
Obligatoriskt
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
Den lokala cachens storlek (i byte).
64GB
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.
bana
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 data-store-caching

NOTE
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 sömlös 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 downloads

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 cachen, kommer vissa filer att tas bort för att frigöra utrymme.

Asynkron överföring async-upload

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 configuring-binaryless-replication-with-amazon-s

Följande steg krävs för att konfigurera en 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 knappen 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 creating-a-cluster-using-s-and-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.

  8. Starta den andra AEM.

Konfigurera ett delat datalager configuring-a-shared-data-store

  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 montera den i <aem-install>/crx-quickstart/install mapp.

    • Om du använder S3 som datalager skapar du en fil med namnet 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. Kommandot du måste köra är:

    code language-xml
    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    
    note note
    NOTE
    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.
    note note
    NOTE
    Du kan hämta verktyget för körning från följande plats:
    https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run/
    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:
    code language-none
    * 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 till sist. Du validerar genom att leta efter en unik fil som 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 datalagermappen.
    • För S3DataStore filerna skapas i den konfigurerade S3-bucket under META mapp.

Azure Data Store 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 Repository 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).

NOTE
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 måste 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 anslutningsprogrammet har stöd för Azure Shared Access Signature (SAS) lagts 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 '=' escape-konverteras som '='.

  • azureBlobEndpoint="": Azure Blob Endpoint. 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 '=' escape-konverteras som '='.

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

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

  • maxErrorRetry="": Antal fö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: Sökvägen till datalagret. 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 med 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 delad datalagringsinställning.
  • stagingSplitPercentage: Den procentandel av cachestorleken som har konfigurerats för 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).
NOTE
Alla inställningar ska anges mellan citattecken, till exempel:
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Skräpinsamling för datalager data-store-garbage-collection

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

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

    note note
    NOTE
    The markOnly parameter anger om skräpinsamlingens svepfas körs eller inte.

Skräpinsamling för datalager för ett delat datalager data-store-garbage-collection-for-a-shared-data-store

NOTE
När du utför skräpinsamling i ett klustrat eller delat datalager kan loggen konfigureras (med mongo- eller segmentmål) med varningsmeddelanden om att vissa blob-ID inte kan tas bort. Blob-ID:n som tagits bort i en tidigare skräpinsamling refereras felaktigt 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.
NOTE
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. Överväg att inaktivera BlobTracker för alla författare- och publiceringsinstanser genom att göra 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. Så här kan du 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.

    Alla filer som hittas sorteras med markeringsfasen som användes före och tar bort resten som inte används från datalagret.

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