Show Menu
ARGOMENTI×

Configurazione di archivi di nodi e archivi di dati in AEM 6

Introduzione

In Adobe Experience Manager (AEM), i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. I dati binari sono memorizzati in un archivio dati, mentre i nodi di contenuto sono memorizzati in un archivio nodi.
Entrambi gli archivi di dati e gli archivi di nodi possono essere configurati utilizzando la configurazione OSGi. A ogni configurazione OSGi viene fatto riferimento tramite un identificatore permanente (PID).

Passaggi di configurazione

Per configurare sia l'archivio nodi che l'archivio dati, procedere come segue:
  1. Copiate il file AEM QuickStart JAR nella directory di installazione.
  2. Create una cartella crx-quickstart/install nella directory di installazione.
  3. Innanzitutto, configurate l'archivio nodi creando un file di configurazione con il nome dell'opzione dell'archivio nodi che desiderate utilizzare nella crx-quickstart/install directory.
    Ad esempio, l'archivio dei nodi del documento (che è la base per l'implementazione MongoMK di AEM) utilizza il file org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config .
  4. Modificate il file e impostate le opzioni di configurazione.
  5. Creare un file di configurazione con il PID dell'archivio dati che si desidera utilizzare. Modificate il file per impostare le opzioni di configurazione.
    Per le opzioni di configurazione, consulta Configurazione archivio nodi e configurazioni archivio dati.
  6. Avviate AEM.

Configurazioni archivio nodi

Le versioni più recenti di Oak utilizzano un nuovo schema di denominazione e un nuovo formato per i file di configurazione OSGi. Il nuovo schema di denominazione richiede che il file di configurazione sia denominato .config e che il nuovo formato richieda la digitazione di valori e la documentazione seguente .
Se esegui l’aggiornamento da una versione precedente di Oak, accertati di eseguire prima un backup della crx-quickstart/install cartella. Dopo l'aggiornamento, ripristinare il contenuto della cartella all'installazione aggiornata e modificare l'estensione dei file di configurazione da .cfg a .config .
Nel caso in cui leggiate questo articolo in preparazione dell'aggiornamento da un'installazione AEM 5.x , accertatevi di consultare prima la documentazione relativa all' aggiornamento .

Archivio nodi segmento

L’archivio dei nodi del segmento è alla base dell’implementazione TarMK di Adobe in AEM6. Utilizza il org.apache.jackrabbit.oak.segment.SegmentNodeStoreService PID per la configurazione.
Il PID per l’archivio dei nodi del segmento è cambiato da AEM 6 a org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions org.apache.jackrabbit.oak.segment.SegmentNodeStoreService AEM 6.3. Accertatevi di apportare le modifiche necessarie alla configurazione per riflettere questa modifica.
Potete configurare le seguenti opzioni:
  • repository.home : Percorso della home directory archivio in cui vengono memorizzati i dati relativi all'archivio. Per impostazione predefinita, i file dei segmenti sono memorizzati nella crx-quickstart/segmentstore directory.
  • tarmk.size : Dimensione massima di un segmento in MB. Il valore massimo predefinito è 256 MB.
  • customBlobStore : Valore booleano che indica l'utilizzo di un archivio dati personalizzato. Il valore predefinito è true per AEM 6.3 e versioni successive. Prima di AEM 6.3, il valore predefinito era false.
Segue un org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config file di esempio:
#Path to repo
repository.home="crx-quickstart/repository"

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

#Custom data store
customBlobStore=B"true"

Archivio nodi documento

L'archivio dei nodi del documento è alla base dell'implementazione di AEM MongoMK. Utilizza il PID org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService *. Sono disponibili le seguenti opzioni di configurazione:
  • mongouri : Il MongoURI richiesto per connettersi al database Mongo. Il valore predefinito è mongodb://localhost:27017
  • db : Nome del database Mongo. Il valore predefinito è Oak . However, new AEM 6 installations use **aem-author** come nome predefinito del database.
  • cache : Dimensione della cache in MB. Questo viene distribuito tra diverse cache utilizzate in DocumentNodeStore. Il valore predefinito è 256
  • changesSize : Dimensioni in MB della raccolta limitata utilizzata in Mongo per memorizzare nella cache l'output delle diff. Il valore predefinito è 256
  • customBlobStore : Valore booleano che indica che verrà utilizzato un archivio dati personalizzato. Il valore predefinito è false .
Segue un org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config file di esempio:
#Mongo server details
mongouri="mongodb://localhost:27017"

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

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

Configurazioni archivio dati

Per gestire un numero elevato di file binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi nodo predefiniti, al fine di massimizzare le prestazioni.
Ad esempio, se il progetto richiede un numero elevato di risorse multimediali, memorizzarle nel file o nell'archivio dati S3 consente di accedervi più rapidamente che archiviarle direttamente in un MongoDB.
File Data Store offre prestazioni migliori rispetto a MongoDB, e le operazioni di backup e ripristino di Mongo sono anche più lente con un gran numero di risorse.
Di seguito sono descritti i dettagli relativi ai diversi data store e configurazioni.
Per abilitare gli archivi dati personalizzati, devi accertarti che customBlobStore sia impostato true nel file di configurazione Node Store corrispondente (archivio nodi segmento o archivio nodi documento).

Archivio file di dati

Questa è l'implementazione di FileDataStore presente in Jackrabbit 2. Fornisce un modo per memorizzare i dati binari come file normali sul file system. Utilizza il org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore PID.
Sono disponibili le seguenti opzioni di configurazione:
  • repository.home : Percorso della home directory archivio in cui vengono memorizzati i vari dati relativi al repository. Per impostazione predefinita, i file binari vengono memorizzati nella crx-quickstart/repository/datastore directory
  • path : Percorso della directory in cui vengono memorizzati i file. Se specificato, ha precedenza sul repository.home valore
  • minRecordLength : La dimensione minima in byte di un file memorizzato nell'archivio dati. Il contenuto binario inferiore a questo valore viene allineato.
Quando si utilizza un NAS per memorizzare gli archivi di dati dei file condivisi, assicurarsi di utilizzare solo dispositivi con prestazioni elevate per evitare problemi di prestazioni.

Amazon S3 Data Store

AEM può essere configurato per memorizzare i dati in Amazon Simple Storage Service (S3). Utilizza il org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config PID per la configurazione.
Per abilitare la funzionalità dell'archivio dati S3, è necessario scaricare e installare un feature pack contenente il connettore S3 Datastore. Accedete ad Adobe Repository e scaricate l'ultima versione dalle versioni 1.10.x del feature pack (ad esempio, com.adobe.granite.oak.s3Connector-1.10.0.zip). Inoltre, devi scaricare e installare l’ultimo service pack AEM elencato nella pagina Note sulla versione di AEM 6.5.
Quando si utilizza AEM con TarMK, per impostazione predefinita i file binari vengono memorizzati in FileDataStore . Per utilizzare TarMK con il datastore S3, è necessario avviare AEM utilizzando la crx3tar-nofds modalità di esecuzione, ad esempio:
java -jar <aem-jar-file>.jar -r crx3tar-nofds

Una volta scaricato, è possibile installare e configurare il connettore S3 come segue:
  1. Estrarre il contenuto del file zip del pacchetto di funzioni in una cartella temporanea.
  2. Passate alla cartella temporanea e individuate il percorso seguente:
    jcr_root/libs/system/install
    
    
    Copiate tutti i contenuti dalla posizione precedente a <aem-install>/crx-quickstart/install.
  3. Se AEM è già configurato per l'utilizzo dell'archivio Tar o MongoDB, rimuovete eventuali file di configurazione esistenti dalla cartella ***<aem-install>***/ crx-quickstart / install prima di continuare. I file da rimuovere sono:
    • For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    • For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Tornate nella posizione temporanea in cui è stato estratto il pacchetto di funzioni e copiate il contenuto della cartella seguente:
    • jcr_root/libs/system/config a
    • <aem-install>/crx-quickstart/install Accertatevi di copiare solo i file di configurazione richiesti dalla configurazione corrente. Per un archivio dati dedicato e una configurazione dell'archivio dati condivisa, copiare il org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config file.
    In una configurazione cluster, eseguite i passaggi sopra descritti su tutti i nodi del cluster uno per uno. Inoltre, accertatevi di utilizzare le stesse impostazioni S3 per tutti i nodi.
  5. Modificate il file e aggiungete le opzioni di configurazione richieste dalla configurazione.
  6. Avviate AEM.

Aggiornamento a una nuova versione del connettore S3 1.8.x

Per effettuare l'aggiornamento a una nuova versione del connettore S3 1.8.x (ad esempio, da 1.8.0 a 1.8.1), procedere come segue:
  1. Arrestate l’istanza AEM.
  2. Accedete <aem-install>/crx-quickstart/install/15 alla cartella di installazione di AEM e eseguite un backup del relativo contenuto.
  3. Dopo il backup, eliminare la vecchia versione del S3 Connector e le sue dipendenze eliminando tutti i file jar nella <aem-install>/crx-quickstart/install/15 cartella, ad esempio:
    • quercia-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    I nomi di file riportati sopra sono utilizzati solo a scopo illustrativo e non sono definitivi.
  4. Scaricate l'ultima versione del pacchetto di funzioni 1.8.x dall'archivio di Adobe .
  5. Decomprimete il contenuto in una cartella separata, quindi passate a jcr_root/libs/system/install/15 .
  6. Copiate i file jar in <aem-install> /crx-quickstart/install/15 nella cartella di installazione di AEM.
  7. Avviate AEM e verificate la funzionalità del connettore.
Potete utilizzare il file di configurazione con le seguenti opzioni:
  • accessKey: La chiave di accesso AWS.
  • secretKey: La chiave di accesso segreta AWS. Nota: In alternativa, è possibile utilizzare i ruoli java-dg-roles.html IAM per l'autenticazione. Se utilizzate i ruoli IAM, non è più necessario specificare il accessKey e secretKey .
  • s3Bucket: Il nome del bucket.
  • s3Region: La regione del bucket.
  • percorso: Percorso dell'archivio dati. Il valore predefinito è <cartella di installazione AEM>/repository/datastore
  • minRecordLength: La dimensione minima di un oggetto da memorizzare nell'archivio dati. Il valore minimo/predefinito è 16 KB.
  • maxCachedBinarySize: I file binari con dimensioni inferiori o uguali a queste dimensioni verranno memorizzati nella cache della memoria. La dimensione è espressa in byte. Il valore predefinito è **17408 **(17 KB).
  • cacheSize: Dimensione della cache. Il valore è specificato in byte. Il valore predefinito è 64 GB .
  • secret: Da utilizzare solo se si utilizza la replica binaryless per l'impostazione del datastore condiviso.
  • stagingSplitPercentage: Percentuale della dimensione della cache configurata per l'esecuzione di operazioni di caricamento asincrone. Il valore predefinito è 10 .
  • uploadThread: Numero di thread di caricamento utilizzati per i caricamenti asincroni. Il valore predefinito è 10 .
  • stagingPurgeInterval: L'intervallo in secondi per l'eliminazione dei caricamenti completati dalla cache di staging. Il valore predefinito è 300 secondi (5 minuti).
  • stagingRetryInterval: L'intervallo di tentativi in secondi per i caricamenti non riusciti. Il valore predefinito è 600 secondi (10 minuti).

Opzioni regione intervalli

Standard USA us-standard
Stati Uniti us-west-2
US West (California del Nord) us-west-1
UE (Irlanda) EU
Asia Pacifico (Singapore) ap-southeast-1
Asia Pacifico (Sydney) ap-southeast-2
Asia Pacifico (Tokyo) ap-northeast-1
Sud America (San Paolo) sa-east-1
Memorizzazione nella cache
Le implementazioni di DataStore del S3DataStore caching dei file system locali CachingFileDataStore e AzureDataStore supportano tale funzionalità. L' CachingFileDataStore implementazione è utile quando DataStore è su NFS (Network File System).
Quando si esegue l'aggiornamento da una precedente implementazione della cache (prima di Oak 1.6), si verifica una differenza nella struttura della directory della cache del file system locale. Nella vecchia struttura della cache, sia i file scaricati che quelli caricati venivano inseriti direttamente nel percorso della cache. La nuova struttura separa i download e i caricamenti e li memorizza in due directory denominate upload e download nel percorso della cache. Il processo di aggiornamento dovrebbe essere senza soluzione di continuità e tutti i caricamenti in sospeso dovrebbero essere pianificati per il caricamento e tutti i file precedentemente scaricati nella cache verranno inseriti nella cache al momento dell'inizializzazione.
È inoltre possibile aggiornare la cache offline utilizzando il datastorecacheupgrade comando di esecuzione della quercia. Per informazioni dettagliate su come eseguire il comando, controllare il modulo Leggimi per l'esecuzione della quercia.
La cache ha un limite di dimensione e può essere configurata utilizzando il parametro cacheSize.
Download
La cache locale verrà controllata per verificare il record del file/BLOB richiesto prima di accedervi da DataStore. Quando la cache supera il limite configurato (vedere il cacheSize parametro) durante l'aggiunta di un file nella cache, alcuni dei file verranno rimossi per recuperare spazio.
Caricamento asincrono
La cache supporta i caricamenti asincroni in DataStore. I file vengono memorizzati localmente, nella cache (del file system), e un processo asincrono inizia a caricare il file. Il numero di caricamenti asincroni è limitato dalla dimensione della cache di staging. La dimensione della cache di staging è configurata utilizzando il stagingSplitPercentage parametro . Questo parametro definisce la percentuale di dimensione della cache da utilizzare per la cache di staging. Inoltre, la percentuale di cache disponibile per i download è calcolata come (100 - stagingSplitPercentage ) * cacheSize .
I caricamenti asincroni sono multithread e il numero di thread è configurato utilizzando il uploadThreads parametro.
Al termine dei caricamenti, i file vengono spostati nella cache di download principale. Quando la dimensione della cache di staging supera il limite, i file vengono caricati in modo sincrono in DataStore fino al completamento dei precedenti caricamenti asincroni e allo spazio disponibile nuovamente nella cache di staging. I file caricati vengono rimossi dall'area di gestione temporanea tramite un processo periodico il cui intervallo è configurato dal stagingPurgeInterval parametro.
I caricamenti non riusciti (ad esempio a causa di un'interruzione di rete) vengono messi in coda e riprovati periodicamente. L'intervallo dei tentativi è configurato utilizzando l' stagingRetryInterval parameter .

Configurazione della replica binaryless con Amazon S3

Per configurare la replica binaryless con S3, sono necessari i seguenti passaggi:
  1. Installate le istanze di creazione e pubblicazione e accertatevi che siano avviate correttamente.
  2. Passate alle impostazioni dell'agente di replica, aprendo una pagina a https://localhost:4502/etc/replication/agents.author/publish.html .
  3. Premere il pulsante Modifica nella sezione Impostazioni .
  4. Cambia l’opzione Tipo serializzazione in binario minore .
  5. Aggiungete il parametro " binaryless = true " nell’uri di trasporto. Dopo la modifica, l'URI deve essere simile al seguente:
    https://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true
  6. Riavviate tutte le istanze di creazione e pubblicazione per rendere effettive le modifiche.

Creazione di un cluster con S3 e MongoDB

  1. Scomprimete CQ QuickStart con il seguente comando:
    java -jar cq-quickstart.jar -unpack
  2. Dopo aver decompresso AEM, create una cartella all’interno della directory di installazione crx-quickstart / install .
  3. Create questi due file all’interno della crx-quickstart cartella:
    • org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService . config
    • org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore . config Dopo aver creato i file, aggiungete le opzioni di configurazione necessarie.
  4. Installare i due pacchetti richiesti per l'archivio dati S3 come descritto sopra.
  5. Verificare che MongoDB sia installato e che un'istanza di mongod sia in esecuzione.
  6. Avviate AEM con il comando seguente:
    java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo
  7. Ripetete i passaggi da 1 a 4 per la seconda istanza di AEM.
  8. Avviate la seconda istanza di AEM.

Configurazione di un archivio dati condiviso

  1. Innanzitutto, creare il file di configurazione dell'archivio dati su ogni istanza necessaria per condividere l'archivio dati:
    • Se usate un file FileDataStore , create un file denominato org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config e inseritelo nella <aem-install>/crx-quickstart/install cartella.
    • Se si utilizza S3 come archivio dati, creare un file denominato o rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config nella <aem-install>/crx-quickstart/install cartella come indicato sopra.
  2. Modificare i file di configurazione dell'archivio dati in ogni istanza in modo che puntino allo stesso archivio dati. Per ulteriori informazioni, consultate questo articolo .
  3. Se l’istanza è stata duplicata da un server esistente, è necessario rimuovere l’istanza clusterId della nuova istanza utilizzando lo strumento di esecuzione della quercia più recente mentre l’archivio è offline. Il comando da eseguire è:
    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    
    
    Se è configurato un archivio nodi Segmento, è necessario specificare il percorso del repository. Per impostazione predefinita, il percorso è <aem-install-folder>/crx-quickstart/repository/segmentstore. Se è configurato un archivio nodi del documento, è possibile utilizzare un URI stringa di connessione Mongo.
    Lo strumento di esecuzione Oak può essere scaricato da questo percorso:
    È necessario utilizzare diverse versioni dello strumento a seconda della versione Oak utilizzata con l’installazione di AEM. Prima di utilizzare lo strumento, controllare l'elenco dei requisiti di versione riportato di seguito:
    • Per le versioni di Oak 1.2.x , utilizzate la versione di Oak 1.2.12 o successiva
    • Per le versioni Oak più recenti rispetto a quelle precedenti , utilizzate la versione di Oak-run che corrisponda al core Oak dell’installazione AEM.
  4. Infine, convalidare la configurazione. A questo scopo, è necessario cercare un file univoco aggiunto all'archivio dati da ogni repository che lo condivide. Il formato dei file è repository-[UUID] , dove l’UUID è un identificatore univoco di ciascun repository.
    Di conseguenza, una configurazione corretta deve contenere tutti i file univoci presenti nei repository che condividono l'archivio dati.
    I file vengono memorizzati in modo diverso, a seconda dell'archivio dati:
    • Per FileDataStore i file vengono creati nel percorso principale della cartella dell'archivio dati.
    • Per S3DataStore i file vengono creati nel bucket S3 configurato sotto la META cartella.

Archivio dati Azure

AEM può essere configurato per memorizzare i dati nel servizio di archiviazione di Microsoft Azure. Utilizza il org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config PID per la configurazione.
Per abilitare la funzionalità dell'archivio dati di Azure, è necessario scaricare e installare un feature pack contenente il connettore di Azure. Accedete ad Adobe Repository e scaricate l'ultima versione dalle versioni 1.6.x del feature pack (ad esempio, com.adobe.granite.oak.azureblobConnector-1.6.3.zip).
Quando si utilizza AEM con TarMK, per impostazione predefinita i file binari vengono memorizzati in FileDataStore. Per utilizzare TarMK con Azure DataStore, è necessario avviare AEM utilizzando la crx3tar-nofds modalità di esecuzione, ad esempio:
java -jar <aem-jar-file>.jar -r crx3tar-nofds

Una volta scaricato, è possibile installare e configurare il connettore Azure come segue:
  1. Estrarre il contenuto del file zip del pacchetto di funzioni in una cartella temporanea.
  2. Passate alla cartella temporanea e copiate il contenuto della cartella jcr_root/libs/system/install in <aem-install>crx-quickstart/install .
  3. Se AEM è già configurato per l'utilizzo dell'archivio Tar o MongoDB, rimuovete tutti i file di configurazione esistenti dalla /crx-quickstart/install cartella prima di continuare. I file da rimuovere sono:
    ForMongoMK:
    org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    Per TarMK:
    org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Tornate alla posizione temporanea in cui è stato estratto il pacchetto di funzioni e copiate il contenuto jcr_root/libs/system/config nella <aem-install>/crx-quickstart/install cartella.
  5. Modificate il file di configurazione e aggiungete le opzioni di configurazione richieste dalla configurazione.
  6. Avviate AEM.
Potete utilizzare il file di configurazione con le seguenti opzioni:
  • azureSas="": Nella versione 1.6.3 del connettore, è stato aggiunto il supporto SAS (Shared Access Signature) di Azure. Se nel file di configurazione esistono sia le credenziali SAS che quelle di archiviazione, SAS ha priorità. Per ulteriori informazioni su SAS vedere la documentazione storage-dotnet-shared-access-signature-part-1ufficiale. Assicurarsi che il carattere '=' sia preceduto da un carattere con carattere di escape come '\='.
  • azureBlobEndpoint="": Endpoint BLOB di Azure. Ad esempio, https://<account-archivio>.blob.core.windows.net.
  • accessKey="": Nome account di archiviazione. Per ulteriori dettagli sulle credenziali di autenticazione di Microsoft Azure, consulta la documentazione storage-create-storage-accountufficiale.
  • secretKey="": Chiave di accesso allo storage. Assicurarsi che il carattere '=' sia preceduto da un carattere con carattere di escape come '\='.
  • container="": Nome del contenitore di archiviazione BLOB di Microsoft Azure. Il contenitore è un raggruppamento di un set di BLOB. Per ulteriori dettagli, consultare la documentazione dd135715.aspxufficiale.
  • maxConnections="": Numero simultaneo di richieste simultanee per operazione. Il valore predefinito è 1.
  • maxErrorRetry="": Numero di tentativi per richiesta. Il valore predefinito è 3.
  • socketTimeout="": Intervallo di timeout, in millisecondi, utilizzato per la richiesta. Il valore predefinito è 5 minuti.
Oltre alle impostazioni precedenti, è possibile configurare anche le seguenti impostazioni:
  • percorso: Percorso dell'archivio dati. Il valore predefinito è <aem-install>/repository/datastore.
  • LunghezzaRecord: La dimensione minima di un oggetto da memorizzare nell'archivio dati. Il valore predefinito è 16 KB.
  • maxCachedBinarySize: I file binari con dimensioni inferiori o uguali a queste dimensioni verranno memorizzati nella cache della memoria. La dimensione è espressa in byte. Il valore predefinito è 17408 (17 KB).
  • cacheSize: Dimensione della cache. Il valore è specificato in byte. Il valore predefinito è 64 GB.
  • secret: Da utilizzare solo se si utilizza la replica binaryless per l'impostazione del datastore condiviso.
  • stagingSplitPercentage: Percentuale della dimensione della cache configurata per l'esecuzione di operazioni di caricamento asincrone. Il valore predefinito è 10.
  • uploadThread: Numero di thread di caricamento utilizzati per i caricamenti asincroni. Il valore predefinito è 10.
  • stagingPurgeInterval: L'intervallo in secondi per l'eliminazione dei caricamenti completati dalla cache di staging. Il valore predefinito è 300 secondi (5 minuti).
  • stagingRetryInterval: L'intervallo di tentativi in secondi per i caricamenti non riusciti. Il valore predefinito è 600 secondi (10 minuti).
Tutte le impostazioni devono essere inserite tra virgolette, ad esempio:
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Data store garbage collection

Il processo di raccolta dei rifiuti dell'archivio dati viene utilizzato per rimuovere eventuali file non utilizzati nell'archivio dati, liberando così spazio prezioso su disco nel processo.
È possibile eseguire la raccolta dei rifiuti dell'archivio dati tramite:
  1. Passate alla console JMX che si trova in https://<serveraddress:port>/system/console/jmx
  2. Ricerca di RepositoryManagement. Una volta trovato il file MBean di Repository Manager, fare clic su di esso per visualizzare le opzioni disponibili.
  3. Scorrete fino alla fine della pagina e fate clic sul collegamento startDataStoreGC(boolean markOnly) .
  4. Nella finestra di dialogo seguente, inserite false il markOnly parametro, quindi fate clic su Richiama :
    Il markOnly parametro indica se la fase di sweep del processo di garbage collection verrà eseguita o meno.

Raccolta di oggetti inattivi nell'archivio dati per un archivio dati condiviso

Durante l'esecuzione della raccolta dei dati in un'impostazione dell'archivio dati cluster o condiviso (con Mongo o Segment Tar), il registro potrebbe visualizzare avvisi sull'impossibilità di eliminare alcuni ID BLOB. Ciò accade perché gli ID BLOB eliminati in una precedente raccolta di oggetti inattivi sono erroneamente citati da altri nodi cluster o condivisi che non dispongono di informazioni sulle eliminazioni ID. Di conseguenza, quando viene eseguita la raccolta di oggetti inattivi, viene registrato un avviso quando si tenta di eliminare un ID già eliminato nell'ultima esecuzione. Questo comportamento non influisce sulle prestazioni o sulle funzionalità.
Con le versioni più recenti di AEM, la raccolta dei rifiuti nell'archivio dati può essere eseguita anche sugli store dati condivisi da più repository. Per poter eseguire la raccolta dei rifiuti dell'archivio dati in un archivio dati condiviso, effettuare le seguenti operazioni:
  1. Assicurarsi che tutte le attività di manutenzione configurate per la raccolta dei rifiuti dell'archivio dati siano disattivate in tutte le istanze dell'archivio che condividono l'archivio dati.
  2. Eseguire i passaggi indicati in Binary Garbage Collection singolarmente su tutte le istanze del repository che condividono l'archivio dati. Tuttavia, accertatevi di inserire true il markOnly parametro prima di fare clic sul pulsante Richiama:
  3. Dopo aver completato la procedura sopra riportata su tutte le istanze, eseguire di nuovo il processo di garbage collection dell'archivio dati da una delle istanze:
    1. Accedete alla console JMX e selezionate Repository Manager Mbay.
    2. Fare clic sul collegamento Click startDataStoreGC(booleano markOnly) .
    3. Nella finestra di dialogo seguente, immettete di nuovo false il markOnly parametro. In questo modo verranno raccolti tutti i file trovati utilizzando la fase di contrassegno utilizzata in precedenza ed eliminati gli altri file non utilizzati dall'archivio dati.