Configurazione degli archivi di nodi e degli archivi di dati nel AEM 6

Introduzione

In Adobe Experience Manager (AEM), i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. I dati binari vengono memorizzati in un archivio dati, mentre i nodi di contenuto sono memorizzati in un archivio nodi.

È possibile configurare sia gli archivi di dati che gli archivi dei nodi utilizzando la configurazione OSGi. A ogni configurazione OSGi viene fatto riferimento utilizzando un identificatore permanente (PID).

Passaggi di configurazione

Per configurare sia l'archivio nodi che l'archivio dati, esegui questi passaggi:

  1. Copia il file JAR AEM quickstart nella relativa directory di installazione.

  2. Crea una cartella crx-quickstart/install nella directory di installazione.

  3. Per prima cosa, configura l'archivio nodi creando un file di configurazione con il nome dell'opzione dell'archivio nodi che desideri utilizzare nella directory crx-quickstart/install.

    Ad esempio, l'archivio dei nodi Document (che è la base per AEM'implementazione MongoMK) utilizza il file org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config.

  4. Modifica il file e imposta le opzioni di configurazione.

  5. Crea un file di configurazione con il PID dell’archivio dati che desideri utilizzare. Modifica il file per impostare le opzioni di configurazione.

    NOTA

    Per le opzioni di configurazione, consulta Configurazioni archivio nodi e Configurazioni archivio dati .

  6. Inizia AEM.

Configurazioni dell'archivio nodi

ATTENZIONE

Le versioni più recenti di Oak utilizzano un nuovo schema e formato di denominazione 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 ed è documentato qui.

Se esegui l’aggiornamento da una versione precedente di Oak, assicurati di eseguire prima un backup della cartella crx-quickstart/install. Dopo l'aggiornamento, ripristina il contenuto della cartella nell'installazione aggiornata e modifica l'estensione dei file di configurazione da .cfg a .config.

Se leggi questo articolo in preparazione di un aggiornamento da un'installazione di AEM 5.x, assicurati di consultare prima la documentazione upgrade .

Archivio dei nodi del segmento

L’archivio dei nodi del segmento è la base dell’implementazione TarMK di Adobe in AEM6. Utilizza il org.apache.jackrabbit.oak.segment.SegmentNodeStoreService PID per la configurazione.

ATTENZIONE

Il PID per l’archivio dei nodi di segmento è stato modificato da org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions di AEM 6 a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService in AEM 6.3. Assicurati di effettuare le regolazioni di configurazione necessarie per riflettere questa modifica.

Puoi configurare le seguenti opzioni:

  • repository.home: Percorso della home del repository in cui vengono archiviati i dati relativi al repository. Per impostazione predefinita, i file dei segmenti sono memorizzati nella directory crx-quickstart/segmentstore .

  • tarmk.size: Dimensione massima di un segmento in MB. Il 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.

Di seguito è riportato un file di esempio org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config :

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

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

#Custom data store
customBlobStore=B"true"

Archiviazione dei nodi del documento

L'archivio dei nodi del documento è la base dell'implementazione AEM MongoMK. Utilizza il org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService* *PID. Sono disponibili le seguenti opzioni di configurazione:

  • mongouri: Il 🔗 MongoURIrichiesto 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. Questa viene distribuita tra le varie cache utilizzate in DocumentNodeStore. Il valore predefinito è 256

  • changesSize: Dimensioni in MB della raccolta limitata utilizzata in Mongo per memorizzare nella cache l'output diff. Il valore predefinito è 256

  • customBlobStore: Valore booleano che indica che verrà utilizzato un archivio dati personalizzato. Il valore predefinito è false.

Di seguito è riportato un file di esempio org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config :

#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 dell'archivio dati

Quando si gestisce un numero elevato di binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi nodi predefiniti per 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 all’interno di un MongoDB.

Il File Data Store offre prestazioni migliori rispetto a MongoDB, e le operazioni di backup e ripristino Mongo sono anche più lente con un gran numero di risorse.

Di seguito sono descritti i dettagli sui diversi archivi di dati e configurazioni.

NOTA

Per abilitare gli archivi dati personalizzati, è necessario assicurarsi che customBlobStore sia impostato su true nel rispettivo file di configurazione Node Store (archivio nodi segmento o archivio nodi documento).

Archivio file di dati

Implementazione di FileDataStore presente in Jackrabbit 2. Fornisce un modo per memorizzare i dati binari come file normali sul file system. Utilizza il PID org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.

Sono disponibili le seguenti opzioni di configurazione:

  • repository.home: Percorso della home dell'archivio in cui vengono archiviati vari dati relativi all'archivio. Per impostazione predefinita, i file binari vengono memorizzati nella directory crx-quickstart/repository/datastore

  • path: Percorso della directory in cui vengono archiviati i file. Se specificato, ha la precedenza sul valore repository.home

  • minRecordLength: Dimensione minima in byte di un file archiviato nell'archivio dati. Il contenuto binario inferiore a questo valore viene allineato.

NOTA

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.

Archivio dati Amazon S3

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. Vai al Adobe Repository e scarica 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 come elencato nella pagina AEM Note sulla versione 6.5 .

NOTA

Quando si utilizza AEM con TarMK, i binari vengono memorizzati per impostazione predefinita in FileDataStore. Per utilizzare TarMK con il Datastore S3, è necessario avviare AEM utilizzando la modalità runmode crx3tar-nofds, ad esempio:

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

Una volta scaricato, è possibile installare e configurare il S3 Connector come segue:

  1. Estrarre il contenuto del file zip del feature pack in una cartella temporanea.

  2. Passa alla cartella temporanea e passa al seguente percorso:

    jcr_root/libs/system/install
    

    Copia tutti i contenuti dalla posizione precedente in <aem-install>/crx-quickstart/install.

  3. Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dalla cartella *<aem-install>/crx-quickstart/install prima di procedere. 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. Torna alla posizione temporanea in cui è stato estratto il pacchetto di funzionalità e copia il contenuto della cartella seguente:

    • jcr_root/libs/system/config

    a

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

    Assicurati di copiare solo i file di configurazione necessari per la configurazione corrente. Per un archivio dati dedicato e una configurazione dell'archivio dati condivisa, copia il file org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config.

    NOTA

    In una configurazione cluster, esegui i passaggi sopra descritti su tutti i nodi del cluster uno per uno. Inoltre, assicurati di utilizzare le stesse impostazioni S3 per tutti i nodi.

  5. Modifica il file e aggiungi le opzioni di configurazione richieste dalla configurazione.

  6. Inizia AEM.

Aggiornamento a una nuova versione del connettore S3 1.10.x

Per effettuare l’aggiornamento a una nuova versione del connettore S3 1.10.x (ad esempio, da 1.10.0 a 1.10.4), effettua le seguenti operazioni:

  1. Interrompi l'istanza AEM.

  2. Passa a <aem-install>/crx-quickstart/install/15 nella cartella di installazione di AEM ed effettua un backup del relativo contenuto.

  3. Dopo il backup, elimina la vecchia versione del S3 Connector e le sue dipendenze eliminando tutti i file jar nella cartella <aem-install>/crx-quickstart/install/15, ad esempio:

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

    I nomi di file sopra riportati sono utilizzati solo a scopo illustrativo.

  4. Scarica la versione più recente del pacchetto di funzioni 1.8.x dal Adobe Repository.

  5. Decomprimi il contenuto in una cartella separata, quindi passa a jcr_root/libs/system/install/15.

  6. Copia i file jar in <aem-install>/crx-quickstart/install/15 nella cartella di installazione AEM.

  7. Avvia AEM e controlla la funzionalità del connettore.

Puoi utilizzare il file di configurazione con le seguenti opzioni:

  • accessKey: Chiave di accesso AWS.

  • secretKey: Chiave di accesso segreto AWS. Nota: in alternativa, i ruoli IAM possono essere utilizzati per l'autenticazione. Se utilizzi i ruoli IAM, non è più necessario specificare i valori accessKey e secretKey.

  • s3Bucket: Nome del bucket.

  • s3Region: La regione del bucket.

  • percorso: Percorso dell'archivio dati. Il valore predefinito è <AEM cartella di installazione>/repository/datastore

  • minRecordLength: Dimensione minima di un oggetto che deve essere memorizzato nell'archivio dati. Il valore minimo/predefinito è 16 KB.

  • maxCachedBinarySize: I binari con dimensioni inferiori o uguali a queste dimensioni verranno memorizzati nella cache di 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.

  • segreto: Da utilizzare solo se si utilizza la replica binaryless per l'impostazione di un archivio dati condiviso.

  • stagingSplitPercentage: Percentuale di dimensioni della cache configurate da utilizzare per i caricamenti asincroni di staging. Il valore predefinito è 10.

  • uploadThreads: Il numero di thread di caricamento utilizzati per i caricamenti asincroni. Il valore predefinito è 10.

  • stagingPurgeInterval: Intervallo in secondi per lo svuotamento dei caricamenti completati dalla cache di staging. Il valore predefinito è 300 secondi (5 minuti).

  • stagingRetryInterval: Intervallo dei tentativi in secondi per caricamenti non riusciti. Il valore predefinito è 600 secondi (10 minuti).

Opzioni dell’area a blocchi

Standard USA us-standard
Stati Uniti d'America 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 in cache del DataStore

NOTA

Le implementazioni di DataStore di S3DataStore, CachingFileDataStore e AzureDataStore supportano il caching dei file system locali. L'implementazione CachingFileDataStore è utile quando DataStore è su NFS (Network File System).

Quando si esegue l’aggiornamento da un’implementazione precedente della cache (prima di Oak 1.6), c’è una differenza nella struttura della directory della cache del file system locale. Nella vecchia struttura della cache sia i file scaricati che quelli caricati sono stati messi direttamente sotto il 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.

Puoi anche aggiornare la cache offline utilizzando il comando datastorecacheupgrade di oak-run. Per informazioni dettagliate su come eseguire il comando, controllare readme per il modulo oak-run.

La cache ha un limite di dimensioni e può essere configurata utilizzando il parametro cacheSize.

Download

La cache locale verrà controllata per individuare il record del file/BLOB richiesto prima di accedervi dal DataStore. Quando la cache supera il limite configurato (vedi il parametro cacheSize ) durante l’aggiunta di un file nella cache, alcuni dei file verranno sfrattati per recuperare spazio.

Caricamento asincrono

La cache supporta caricamenti asincroni in DataStore. I file vengono memorizzati localmente, nella cache (nel file system) e inizia un processo asincrono per caricare il file. Il numero di caricamenti asincroni è limitato dalle dimensioni della cache di staging. La dimensione della cache di staging viene configurata utilizzando il parametro stagingSplitPercentage . 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 parametro uploadThreads .

I file vengono spostati nella cache di download principale al termine dei caricamenti. Quando la dimensione della cache di staging supera il limite, i file vengono caricati in modo sincrono nel DataStore fino a quando i caricamenti asincroni precedenti non sono completi e lo spazio è nuovamente disponibile nella cache di staging. I file caricati vengono rimossi dall’area di gestione temporanea da un processo periodico il cui intervallo è configurato dal parametro stagingPurgeInterval .

I caricamenti non riusciti (ad esempio a causa di un’interruzione della rete) vengono messi in una coda di nuovi tentativi e riprovati periodicamente. L'intervallo di tentativi è configurato utilizzando il parametro stagingRetryInterval parameter.

Configurazione della replica binaryless con Amazon S3

Per configurare la replica binaryless con S3, sono necessari i seguenti passaggi:

  1. Installa le istanze di authoring e pubblicazione e assicurati che siano avviate correttamente.

  2. Vai alle impostazioni dell'agente di replica, aprendo una pagina su https://localhost:4502/etc/replication/agents.author/publish.html.

  3. Premere il pulsante Modifica nella sezione Impostazioni.

  4. Cambia l'opzione del tipo Serialization in Binary less.

  5. Aggiungi 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. Riavvia tutte le istanze di authoring e pubblicazione per rendere effettive le modifiche.

Creazione di un cluster utilizzando S3 e MongoDB

  1. Estrai CQ quickstart utilizzando il seguente comando:

    java -jar cq-quickstart.jar -unpack

  2. Dopo AEM scompattato, crea una cartella all'interno della directory di installazione crx-quickstart/install.

  3. Crea questi due file all'interno della cartella crx-quickstart :

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

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

    Dopo aver creato i file, aggiungi le opzioni di configurazione necessarie.

  4. Installa i due bundle necessari per l'archivio dati S3 come spiegato sopra.

  5. Assicurati che MongoDB sia installato e che sia in esecuzione un'istanza di mongod.

  6. Inizia AEM con il seguente comando:

    java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo

  7. Ripetere i passaggi da 1 a 4 per la seconda istanza AEM.

  8. Avvia la seconda istanza AEM.

Configurazione di un archivio dati condiviso

  1. Innanzitutto, crea il file di configurazione dell’archivio dati su ogni istanza necessaria per condividere l’archivio dati:

    • Se utilizzi un file FileDataStore, crea un file denominato org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config e inseriscilo nella cartella <aem-install>/crx-quickstart/install.

    • Se utilizzi S3 come archivio dati, crea un file denominato o rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config nella cartella <aem-install>/crx-quickstart/install come indicato sopra.

  2. Modifica i file di configurazione dell'archivio dati in ogni istanza in modo che puntino allo stesso archivio dati. Per ulteriori informazioni, consulta questo articolo.

  3. Se l’istanza è stata clonata da un server esistente, devi rimuovere la clusterId della nuova istanza utilizzando lo strumento oak-run più recente mentre l’archivio è offline. Il comando da eseguire è:

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

    Se è configurato un archivio dei nodi di segmento, è necessario specificare il percorso del repository. Per impostazione predefinita, il percorso è <aem-install-folder>/crx-quickstart/repository/segmentstore. Se è configurato un archivio dei nodi del documento, è possibile utilizzare un URI della stringa di connessione Mongo.

    NOTA

    Lo strumento Oak-run può essere scaricato da questo percorso:

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

    Tieni presente che è necessario utilizzare diverse versioni dello strumento a seconda della versione Oak utilizzata con l’installazione di AEM. Prima di utilizzare lo strumento, controlla l’elenco dei requisiti di versione riportato di seguito:

    • Per le versioni Oak 1.2.x utilizza l'esecuzione Oak 1.2.12 o successive
    • Per le versioni Oak più recenti rispetto a quanto indicato sopra, utilizza la versione di Oak-run che corrisponde al nucleo Oak dell'installazione AEM.
  4. Infine, convalida la configurazione. A questo scopo, è necessario cercare un file univoco aggiunto all’archivio dati da ogni archivio che lo condivide. Il formato dei file è repository-[UUID], dove l’UUID è un identificatore univoco di ciascun archivio.

    Pertanto, una configurazione corretta deve contenere tutti i file univoci quanti sono gli archivi 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 cartella META .

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 pacchetto di funzioni contenente il connettore di Azure. Vai al Adobe Repository e scarica l'ultima versione dalle versioni 1.6.x del feature pack (ad esempio, com.adobe.granite.oak.azureblobconnector-1.6.3.zip).

NOTA

Quando si utilizza AEM con TarMK, i binari verranno memorizzati per impostazione predefinita nel FileDataStore. Per utilizzare TarMK con Azure DataStore, è necessario avviare AEM utilizzando la modalità di esecuzione crx3tar-nofds, ad esempio:

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

Una volta scaricato, puoi installare e configurare il connettore di Azure come segue:

  1. Estrarre il contenuto del file zip del feature pack in una cartella temporanea.

  2. Vai alla cartella temporanea e copia il contenuto di jcr_root/libs/system/install nella cartella <aem-install>crx-quickstart/install.

  3. Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dalla cartella /crx-quickstart/install prima di procedere. I file da rimuovere sono:

    ForMongoMK:

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

    Per TarMK:

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

  4. Torna alla posizione temporanea in cui è stato estratto il feature pack e copia il contenuto di jcr_root/libs/system/config nella cartella <aem-install>/crx-quickstart/install.

  5. Modifica il file di configurazione e aggiungi le opzioni di configurazione richieste dalla configurazione.

  6. Inizia AEM.

Puoi utilizzare il file di configurazione con le seguenti opzioni:

  • azureSas="": Nella versione 1.6.3 del connettore è stato aggiunto il supporto per la firma di accesso condiviso (SAS) di Azure. Se nel file di configurazione sono presenti sia le credenziali SAS che di archiviazione, SAS ha priorità. Per ulteriori informazioni su SAS, consultare la documentazione ufficiale. Assicurati che il carattere '=' sia preceduto da '='.

  • azureBlobEndpoint="": Endpoint BLOB di Azure. Ad esempio, https://<storage-account>.blob.core.windows.net.

  • accessKey="": Nome dell'account di archiviazione. Per ulteriori dettagli sulle credenziali di autenticazione di Microsoft Azure, consulta la documentazione ufficiale.

  • secretKey="": Chiave di accesso allo storage. Assicurati che il carattere '=' sia preceduto da '='.

  • container="": Nome del contenitore di archiviazione BLOB di Microsoft Azure. Il contenitore è un raggruppamento di un set di BLOB. Per ulteriori informazioni, consulta la documentazione ufficiale.

  • 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 di cui sopra, è possibile configurare anche le seguenti impostazioni:

  • percorso: Percorso dell'archivio dati. Il valore predefinito è <aem-install>/repository/datastore.
  • RecordLength: Dimensione minima di un oggetto che deve essere memorizzato nell'archivio dati. Il valore predefinito è 16 KB.
  • maxCachedBinarySize: I binari con dimensioni inferiori o uguali a queste dimensioni verranno memorizzati nella cache di 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.
  • segreto: Da utilizzare solo se si utilizza la replica binaryless per l'impostazione di un archivio dati condiviso.
  • stagingSplitPercentage: Percentuale di dimensioni della cache configurate da utilizzare per i caricamenti asincroni di staging. Il valore predefinito è 10.
  • uploadThreads: Il numero di thread di caricamento utilizzati per i caricamenti asincroni. Il valore predefinito è 10.
  • stagingPurgeInterval: Intervallo in secondi per lo svuotamento dei caricamenti completati dalla cache di staging. Il valore predefinito è 300 secondi (5 minuti).
  • stagingRetryInterval: Intervallo dei tentativi in secondi per caricamenti non riusciti. Il valore predefinito è 600 secondi (10 minuti).
NOTA

Tutte le impostazioni devono essere inserite tra virgolette, ad esempio:

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

Raccolta rifiuti dell'archivio dati

Il processo di raccolta degli oggetti inattivi dell'archivio dati viene utilizzato per rimuovere tutti i file non utilizzati nell'archivio dati, liberando così spazio prezioso sul disco nel processo.

Puoi eseguire la raccolta degli oggetti inattivi dell'archivio dati:

  1. Andando alla console JMX all'indirizzo https://<serveraddress:port>/system/console/jmx

  2. Ricerca di RepositoryManagement. Una volta trovato il MBean di Repository Manager, fai clic su di esso per visualizzare le opzioni disponibili.

  3. Scorri fino alla fine della pagina e fai clic sul collegamento startDataStoreGC(boolean markOnly) .

  4. Nella finestra di dialogo seguente, immetti false per il parametro markOnly, quindi fai clic su Invoke:

    chlimage_1-9

    NOTA

    Il parametro markOnly indica se la fase di sweep della raccolta degli oggetti inattivi verrà eseguita o meno.

Raccolta rifiuti dell'archivio dati per un archivio dati condiviso

NOTA

Quando si esegue la raccolta oggetti inattivi in una configurazione dell’archivio dati in cluster o condiviso (con Mongo o Segment Tar), il registro potrebbe visualizzare avvisi sull’impossibilità di eliminare determinati ID BLOB. Questo accade perché gli ID BLOB eliminati in una precedente raccolta oggetti inattivi vengono erroneamente referenziati da altri nodi cluster o condivisi che non hanno informazioni sulle eliminazioni degli ID. Di conseguenza, quando si esegue la raccolta 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à.

NOTA

Se utilizzi una configurazione del datastore condiviso e la raccolta degli oggetti inattivi del datastore è disabilitata, l'esecuzione dell'attività di pulizia binaria Lucene può improvvisamente aumentare lo spazio su disco utilizzato. Per evitare questo problema, devi disabilitare BlobTracker su tutte le istanze di authoring e pubblicazione come segue:

  1. Interrompi l'istanza AEM.
  2. Aggiungi il parametro blobTrackSnapshotIntervalInSecs=L"0" nel file crx-quickstart/install/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config. Questo parametro richiede Oak 1.12.0, 1.10.2 o versione successiva.
  3. Riavvia l'istanza AEM.

Con le versioni più recenti di AEM, la raccolta degli oggetti inattivi dell'archivio dati può essere eseguita anche sugli archivi di dati condivisi da più di un archivio. Per poter eseguire la raccolta degli oggetti inattivi dell'archivio dati in un archivio dati condiviso, procedi come segue:

  1. Assicurati che tutte le attività di manutenzione configurate per la raccolta oggetti inattivi dell'archivio dati siano disabilitate su tutte le istanze dell'archivio che condividono l'archivio dati.

  2. Esegui i passaggi indicati in Raccolta rifiuti binari singolarmente su tutte le istanze dell'archivio che condividono l'archivio dati. Tuttavia, assicurati di inserire true per il parametro markOnly prima di fare clic sul pulsante Invoke :

    chlimage_1-10

  3. Dopo aver completato la procedura di cui sopra su tutte le istanze, esegui di nuovo la raccolta oggetti inattivi dell'archivio dati da any delle istanze:

    1. Vai alla console JMX e seleziona il Mbean di Repository Manager.
    2. Fai clic sul collegamento Click startDataStoreGC(boolean markOnly) .
    3. Nella finestra di dialogo seguente, immetti di nuovo false per il parametro markOnly .

    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.

In questa pagina