DocumentazioneAEM 6.4Guida alla distribuzione

Configurazione degli archivi di nodi e degli archivi di dati nel AEM 6 configuring-node-stores-and-data-stores-in-aem

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Creato per:

  • Developer
CAUTION
AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.

Introduzione introduction

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

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. Creare 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 nel crx-quickstart/install directory.

    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.

    note note
    NOTE
    Vedi Configurazioni dell'archivio nodi e Configurazioni dell'archivio dati per le opzioni di configurazione.

  6. Inizia AEM.

Configurazioni dell'archivio nodi node-store-configurations

CAUTION
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 il nuovo formato richiede valori da digitare ed è documentato qui.
Se esegui l’aggiornamento da una versione precedente di Oak, assicurati di effettuare un backup del crx-quickstart/install prima la cartella. Dopo l'aggiornamento, ripristina il contenuto della cartella nell'installazione aggiornata e modifica l'estensione dei file di configurazione da .cfg a .config.
Nel caso in cui tu legga questo articolo in preparazione di un aggiornamento da un AEM 5.x verificare di consultare aggiornamento prima la documentazione.

Archivio dei nodi del segmento segment-node-store

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.

CAUTION
Il PID per l’archivio dei nodi di segmento è stato modificato da org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions del AEM da 6 a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService in AEM 6.3. Assicurati di apportare 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 crx-quickstart/segmentstore directory.

  • 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 esempio org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config file:

#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 document-node-store

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: La MongoURI richiesto per la connessione al database Mongo. Il valore predefinito è mongodb://localhost:27017

  • db: Nome del database Mongo. Il valore predefinito è Oak . Tuttavia, le nuove installazioni AEM 6 utilizzano autore di aem 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 esempio org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config file:

#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 data-store-configurations

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.

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

Archivio file di dati file-data-store

Questa è l'attuazione 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 dell'archivio in cui vengono archiviati vari dati relativi all'archivio. Per impostazione predefinita, i file binari vengono memorizzati in crx-quickstart/repository/datastore directory.

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

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

NOTE
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 amazon-s-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. Vai a Archivio Adobe e scarica la versione più recente dal pacchetto di funzioni versione 1.8.x (ad esempio, com.adobe.granite.oak.s3connector-1.8.0.zip). Inoltre, è necessario scaricare e installare l'ultimo service pack AEM come elencato in Note sulla versione di AEM 6.4 Service Pack pagina.

NOTE
Quando si utilizza AEM 6.4 con TarMK, i binari vengono memorizzati per impostazione predefinita in FileDataStore. Per utilizzare TarMK con il Datastore S3, è necessario iniziare a AEM utilizzando il crx3tar-nofds modalità runmode, ad esempio:
java -jar aem6.4.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:

    code language-xml 
    jcr_root/libs/system/install

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

  3. Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dal 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 org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config file.

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

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

  1. Interrompi l'istanza AEM.

  2. Passa a <aem-install>/crx-quickstart/install/15 nella cartella di installazione AEM e eseguire 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 nel <aem-install>/crx-quickstart/install/15 ad esempio:

    • oak-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    note note
    NOTE
    I nomi dei file sopra riportati sono utilizzati solo a scopo illustrativo e non sono definitivi.

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

  5. Decomprimi il contenuto in una cartella separata, quindi accedi 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: Quando il accessKey o secretKey non viene specificato, quindi il Ruolo IAM viene utilizzato per l'autenticazione.

  • s3Bucket: Nome del bucket.

  • s3Region: La regione del bucket.

  • percorso: Percorso dell'archivio dati. Il valore predefinito è <aem install="" folder="">/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 bucket-region-options

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

NOTE
Implementazioni di DataStore di S3DataStore, CachingFileDataStore e AzureDataStore supporto della memorizzazione in cache del file system locale. La CachingFileDataStore L'implementazione è 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 la datastorecacheupgrade comando di oak-run. Per informazioni dettagliate su come eseguire il comando, controlla la leggimi 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 cacheSize (Parametro) durante l'aggiunta di un file nella cache, alcuni dei file verranno eliminati 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 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 viene calcolata come (100 - stagingSplitPercentage*cacheSize.

I caricamenti asincroni sono multithread e il numero di thread è configurato utilizzando il uploadThreads parametro .

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 dalla stagingPurgeInterval parametro .

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 esecuzione dei nuovi tentativi è configurato utilizzando la variabile stagingRetryInterval parameter.

Configurazione della replica binaryless con Amazon S3 configuring-binaryless-replication-with-amazon-s

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. Passa alle impostazioni dell’agente di replica, aprendo una pagina a http://localhost:4502/etc/replication/agents.author/publish.html.

  3. Premere Modifica nel Impostazioni sezione .

  4. Modificare la Serializzazione opzione digita in Binario meno.

  5. Aggiungi il parametro " binaryless= true" nell'uri di trasporto. Dopo la modifica, l’uri deve essere simile al seguente:

    http://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 creating-a-cluster-using-s-and-mongodb

  1. Estrai CQ quickstart utilizzando il seguente comando:

    java -jar cq-quickstart.jar -unpack

  2. Dopo AEM essere stato decompresso, crea una cartella all’interno della directory di installazione crx-quickstart/installare.

  3. Crea questi due file all'interno del 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, 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 un'istanza di mongod è in esecuzione.

  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 configuring-a-shared-data-store

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

    • Se utilizzi un FileDataStore, crea un file denominato org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config e inserirla nel <aem-install>/crx-quickstart/install cartella.
    • Se utilizzi S3 come archivio dati, crea un file denominato in rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config in <aem-install>/crx-quickstart/install come 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 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 è:

    code language-xml 
    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    note note
    NOTE
    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 nodi documento, è possibile utilizzare un URI stringa di connessione Mongo.
    note note
    NOTE
    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 utilizzare Oak-run 1.2.12 o successivo
    • Per le versioni Oak più recente di quanto sopra, utilizza la versione di Oak-run che corrisponde al nucleo Oak dell'installazione di AEM.

  4. Infine, convalida la configurazione. Per farlo, devi 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 archivio dati.
    • Per S3DataStore i file vengono creati nel bucket S3 configurato sotto il META cartella.

Archivio dati Azure azure-data-store

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 a Archivio Adobe e scarica l’ultima versione dalle versioni 1.6.x del feature pack (ad esempio, com.adobe.granite.oak.azureblobconnector-1.6.3.zip).

NOTE
Quando si utilizza AEM 6.4 con TarMK, i binari verranno memorizzati per impostazione predefinita nel FileDataStore. Per utilizzare TarMK con Azure DataStore, è necessario iniziare a AEM utilizzando il crx3tar-nofds modalità runmode, ad esempio:
java -jar aem6.4.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 al <aem-install>crx-quickstart/install cartella.

  3. Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dal /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 al <aem-install>/crx-quickstart/install cartella.

  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, vedere la sezione 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 sezione 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).
NOTE
Tutte le impostazioni devono essere inserite tra virgolette, ad esempio:
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Raccolta rifiuti dell'archivio dati data-store-garbage-collection

Il processo di raccolta degli oggetti inattivi dell'archivio dati viene utilizzato per rimuovere 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 che si trova in https://<serveraddress:port>/system/console/jmx

  2. Ricerca 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 pulsante startDataStoreGC(booleano markOnly) link.

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

    chlimage_1-122

    note note
    NOTE
    La markOnly Il parametro 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 data-store-garbage-collection-for-a-shared-data-store

NOTE
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à.

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 tutto istanze dell'archivio che condividono l'archivio dati. Tuttavia, assicurati di inserire true per markOnly prima di fare clic sul pulsante Invoke:

    chlimage_1-123

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

    1. Vai alla console JMX e seleziona il Mbean di Repository Manager.
    2. Fai clic sul pulsante Fai clic su startDataStoreGC(booleano markOnly) link.
    3. Nella finestra di dialogo seguente, immetti false per markOnly di nuovo.

    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.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56