Show Menu
TEMAS×

Configuración de almacenes de nodos y almacenes de datos en AEM 6

Introducción

En Adobe Experience Manager (AEM), los datos binarios se pueden almacenar independientemente de los nodos de contenido. Los datos binarios se almacenan en un almacén de datos, mientras que los nodos de contenido se almacenan en un almacén de nodos.
Tanto los almacenes de datos como los almacenes de nodos se pueden configurar mediante la configuración OSGi. Se hace referencia a cada configuración OSGi mediante un identificador persistente (PID).

Pasos de configuración

Para configurar el almacén de nodos y el almacén de datos, lleve a cabo los siguientes pasos:
  1. Copie el archivo JAR de inicio rápido de AEM en su directorio de instalación.
  2. Cree una carpeta crx-quickstart/install en el directorio de instalación.
  3. Primero, configure el almacén de nodos creando un archivo de configuración con el nombre de la opción de almacén de nodos que desee utilizar en el crx-quickstart/install directorio.
    Por ejemplo, el almacén de nodos de Document (que es la base de la implementación MongoMK de AEM) utiliza el archivo org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config .
  4. Edite el archivo y defina las opciones de configuración.
  5. Cree un archivo de configuración con el PID del almacén de datos que desee utilizar. Edite el archivo para establecer las opciones de configuración.
    Consulte Configuraciones del almacén de nodos y Configuraciones del almacén de datos para ver las opciones de configuración.
  6. Inicie AEM.

Configuraciones del almacén de nodos

Las versiones más recientes de Oak emplean un nuevo esquema y formato de nombres para los archivos de configuración OSGi. El nuevo esquema de nombres requiere que el nombre del archivo de configuración sea .config y que el nuevo formato requiera que se escriban valores y se documenten aquí .
Si actualiza desde una versión anterior de Oak, asegúrese de realizar una copia de seguridad de la crx-quickstart/install carpeta en primer lugar. Después de la actualización, restaure el contenido de la carpeta en la instalación actualizada y modifique la extensión de los archivos de configuración de .cfg a .config .
Si está leyendo este artículo como preparación para una actualización desde una instalación de AEM 5.x , asegúrese de consultar primero la documentación de la actualización .

Almacén de nodos de segmento

El almacén de nodos de segmentos es la base de la implementación TarMK de Adobe en AEM6. Utiliza el org.apache.jackrabbit.oak.segment.SegmentNodeStoreService PID para la configuración.
El PID para el almacén de nodos del segmento ha cambiado de AEM 6 a AEM 6.3 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions de org.apache.jackrabbit.oak.segment.SegmentNodeStoreService . Asegúrese de realizar los ajustes de configuración necesarios para reflejar este cambio.
Puede configurar las siguientes opciones:
  • repository.home :: Ruta al directorio raíz del repositorio en el cual se almacenan los datos relacionados con el repositorio. De forma predeterminada, los archivos de segmentos se almacenan en el crx-quickstart/segmentstore directorio.
  • tarmk.size :: Tamaño máximo de un segmento en MB. El máximo predeterminado es 256 MB.
  • customBlobStore :: Valor booleano que indica que se utiliza un almacén de datos personalizado. El valor predeterminado es true para AEM 6.3 y versiones posteriores. Antes de AEM 6.3, el valor predeterminado era false.
A continuación se muestra un org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config archivo de muestra:
#Path to repo
repository.home="crx-quickstart/repository"

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

#Custom data store
customBlobStore=B"true"

Almacén de nodos de documentos

El almacén de nodos de documentos es la base de la implementación de MongoMK de AEM. Utiliza el org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService PID . Están disponibles las siguientes opciones de configuración:
  • mongouri :: El MongoURI necesario para conectarse a la base de datos de Mongo. El valor predeterminado es mongodb://localhost:27017
  • db :: Nombre de la base de datos de Mongo. El valor predeterminado es Oak . Sin embargo, las nuevas instalaciones de AEM 6 utilizan aem-author como nombre de base de datos predeterminado.
  • cache :: El tamaño de caché en MB. Esto se distribuye entre varias cachés utilizadas en DocumentNodeStore. El valor predeterminado es 256 .
  • changesSize :: Tamaño en MB de colección con límite utilizada en Mongo para almacenar en caché la salida de diferencias. El valor predeterminado es 256 .
  • customBlobStore :: Valor booleano que indica que se utilizará un almacén de datos personalizado. El valor predeterminado es false .
A continuación se muestra un org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config archivo de muestra:
#Mongo server details
mongouri="mongodb://localhost:27017"

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

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

Configuraciones del almacén de datos

Cuando se trata de un gran número de binarios, se recomienda utilizar un almacén de datos externo en lugar de los almacenes de nodos predeterminados para maximizar el rendimiento.
Por ejemplo, si el proyecto requiere un gran número de recursos multimedia, almacenarlos en el almacén de datos S3 o File hará que el acceso a ellos sea más rápido que almacenarlos directamente en una base de datos Mongo.
El almacén de datos de archivos ofrece un mejor rendimiento que MongoDB, y las operaciones de backup y restore de Mongo también son más lentas con un gran número de activos.
A continuación se describen los detalles de las diferentes configuraciones y almacenes de datos.
Para habilitar los Almacenes de datos personalizados, debe asegurarse de que customBlobStore está configurado true en el archivo de configuración correspondiente del Almacén de nodos (almacén de nodos de segmentos o almacén de nodos de documentos).

Almacén de datos de archivo

Esta es la implementación de FileDataStore presente en Jackrabbit 2. Proporciona una manera de almacenar los datos binarios como archivos normales en el sistema de archivos. Utiliza el org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore PID.
Estas opciones de configuración están disponibles:
  • repository.home :: Ruta al directorio raíz del repositorio en el cual se almacenan varios datos relacionados con el repositorio. De forma predeterminada, los archivos binarios se almacenarían en crx-quickstart/repository/datastore directorio.
  • path :: Ruta al directorio en el cual se almacenarán los archivos. Si se especifica, tiene prioridad sobre repository.home el valor.
  • minRecordLength :: Tamaño mínimo en bytes de un archivo almacenado en el almacén de datos. El contenido binario menor que este valor se colocaría en la línea.
Al utilizar un NAS para almacenar almacenes de datos de archivos compartidos, asegúrese de utilizar solo dispositivos de alto rendimiento para evitar problemas de performance.

Amazon S3 Data Store

AEM se puede configurar para almacenar datos en el servicio de almacenamiento simple (S3) de Amazon. Utiliza el org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config PID para la configuración.
Para habilitar la funcionalidad del almacén de datos S3, es necesario descargar e instalar un paquete de funciones que contenga el conector del almacén de datos S3. Vaya al repositorio de Adobe y descargue la versión más reciente de las versiones 1.8.x del paquete de funciones (por ejemplo, com.adobe.granite.oak.s3Connector-1.8.0.zip). Además, también debe descargar e instalar el Service Pack más reciente de AEM, tal como se indica en la página de notas de la versión de Service Pack de AEM 6.4.
Al utilizar AEM 6.4 con TarMK, los binarios se almacenarán de forma predeterminada en el FileDataStore . Para utilizar TarMK con el almacén de datos S3, debe iniciar AEM usando el crx3tar-nofds modo de ejecución, por ejemplo:
java -jar aem6.4.jar -r crx3tar-nofds

Una vez descargado, puede instalar y configurar el S3 Connector de la siguiente manera:
  1. Extraiga el contenido del archivo zip del paquete de funciones en una carpeta temporal.
  2. Vaya a la carpeta temporal y vaya a la siguiente ubicación:
    jcr_root/libs/system/install
    
    
    Copie todo el contenido de la ubicación anterior a <aem-install>/crx-quickstart/install.
  3. Si AEM ya está configurado para trabajar con el almacenamiento Tar o MongoDB, elimine los archivos de configuración existentes de la aem-install/crx-quickstart/install carpeta antes de continuar. Los archivos que deben eliminarse son:
    • For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    • For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Vuelva a la ubicación temporal en la que se ha extraído el paquete de funciones y copie el contenido de la siguiente carpeta:
    • jcr_root/libs/system/config
    hasta
    • <aem-install>/crx-quickstart/install
    Asegúrese de que sólo copia los archivos de configuración necesarios para la configuración actual. Copie el org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config archivo tanto para un almacén de datos dedicado como para una configuración compartida del almacén de datos.
    En una configuración de clúster, realice los pasos anteriores en todos los nodos del clúster uno por uno. Además, asegúrese de utilizar la misma configuración de S3 para todos los nodos.
  5. Edite el archivo y agregue las opciones de configuración requeridas por la configuración.
  6. Inicie AEM.

Actualización a una nueva versión del conector 1.8.x S3

Si necesita actualizar a una nueva versión del conector 1.8.x S3 (por ejemplo, de 1.8.0 a 1.8.1), siga estos pasos:
  1. Detenga la instancia de AEM.
  2. Vaya a <aem-install>/crx-quickstart/install/15 la carpeta de instalación de AEM y realice una copia de seguridad de su contenido.
  3. Después de la copia de seguridad, elimine la versión antigua del S3 Connector y sus dependencias eliminando todos los archivos jar de la <aem-install>/crx-quickstart/install/15 carpeta, por ejemplo:
    • oak-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    Los nombres de archivo presentados anteriormente se utilizan únicamente con fines ilustrativos y no son definitivos.
  4. Descargue la versión más reciente del paquete de funciones 1.8.x del repositorio de Adobe.
  5. Descomprima el contenido en una carpeta independiente y, a continuación, vaya a jcr_root/libs/system/install/15 .
  6. Copie los archivos jar en <aem-install> /crx-quickstart/install/15 en la carpeta de instalación de AEM.
  7. Inicie AEM y compruebe la funcionalidad del conector.
Puede utilizar el archivo de configuración con las siguientes opciones:
  • accessKey: Clave de acceso de AWS.
  • secretKey: La clave de acceso secreto de AWS. ​Nota: Como alternativa, las funciones de IAM se pueden usar para la autenticación. Si está utilizando funciones de IAM, ya no necesita especificar el accessKey y secretKey .
  • s3Bucket: El nombre del bloque.
  • s3Region: La región del cubo.
  • path: Ruta del almacén de datos. El valor predeterminado es <carpeta de instalación de AEM>/repositorio/almacén de datos
  • minRecordLength: El tamaño mínimo de un objeto que debe almacenarse en el almacén de datos. El mínimo/predeterminado es de 16 KB.
  • maxCachedBinarySize: Los binarios con un tamaño menor o igual que este tamaño se almacenarán en la memoria caché. El tamaño está en bytes. El valor predeterminado es 17408 (17 KB).
  • cacheSize: El tamaño de la caché. El valor se especifica en bytes. El valor predeterminado es 64 GB .
  • secret: Solo se debe utilizar si se utiliza replicación sin binarios para la configuración del almacén de datos compartido.
  • stagingSplitPerpercentage: El porcentaje de tamaño de caché configurado para utilizarse en cargas asincrónicas de ensayo. El valor predeterminado es 10 .
  • uploadThwords: Número de subprocesos de carga que se utilizan para cargas asincrónicas. El valor predeterminado es 10 .
  • stagingPurgeInterval: El intervalo en segundos para la depuración de cargas terminadas desde la caché de ensayo. El valor predeterminado es 300 segundos (5 minutos).
  • stagingRetryInterval: Intervalo de reintentos en segundos para cargas fallidas. El valor predeterminado es 600 segundos (10 minutos).

Opciones de región de cubo

US Standard us-standard
Estados Unidos Occidental us-west-2
Estados Unidos Occidental (California del Norte) us-west-1
UE (Irlanda) EU
Asia-Pacífico (Singapur) ap-southeast-1
Asia-Pacífico (Sídney) ap-southeast-2
Asia-Pacífico (Tokio) ap-northeast-1
Sudamérica (São Paulo) sa-east-1
Almacenamiento en caché de DataStore
Las implementaciones de DataStore de S3DataStore y CachingFileDataStore admiten el almacenamiento en caché del sistema de archivos local AzureDataStore . La CachingFileDataStore implementación es útil cuando DataStore está en NFS (Network File System).
Al realizar la actualización desde una implementación de caché anterior (anterior a Oak 1.6), existe una diferencia en la estructura del directorio de caché del sistema de archivos local. En la antigua estructura de caché, tanto los archivos descargados como los cargados se colocaron directamente debajo de la ruta de la caché. La nueva estructura segrega las descargas y cargas y las almacena en dos directorios denominados upload y download bajo la ruta de la memoria caché. El proceso de actualización debe ser fluido y cualquier carga pendiente debe programarse para cargarse y cualquier archivo descargado anteriormente en la caché se colocará en la caché al inicializarse.
También puede actualizar la caché sin conexión mediante el datastorecacheupgrade comando oak-run. Para obtener más información sobre cómo ejecutar el comando, consulte el archivo léame del módulo de ejecución de roble.
La caché tiene un límite de tamaño y se puede configurar usando el parámetro cacheSize.
Descargas
Se buscará en la caché local el registro del archivo o blob solicitado antes de acceder a él desde DataStore. Cuando la caché supera el límite configurado (consulte el cacheSize parámetro) al agregar un archivo a la caché, algunos de los archivos se desalojarán para recuperar espacio.
Carga asincrónica
La caché admite cargas asincrónicas en DataStore. Los archivos se escalonan localmente, en la caché (en el sistema de archivos) y un trabajo asincrónico comienza a cargar el archivo. El número de cargas asincrónicas está limitado por el tamaño de la caché de ensayo. El tamaño de la caché de ensayo se configura mediante el stagingSplitPercentage parámetro . Este parámetro define el porcentaje de tamaño de caché que se utilizará para la caché de ensayo. Además, el porcentaje de caché disponible para descargas se calcula como (100 - stagingSplitPercentage ) &ast; cacheSize .
Las cargas asincrónicas son de varios subprocesos y el número de subprocesos se configura mediante el uploadThreads parámetro .
Los archivos se mueven a la caché de descarga principal una vez finalizadas las cargas. Cuando el tamaño de caché de ensayo supera su límite, los archivos se cargan sincrónicamente en DataStore hasta que se completen las cargas asincrónicas anteriores y vuelva a haber espacio disponible en la caché de ensayo. Los archivos cargados se eliminan del área de ensayo mediante un trabajo periódico cuyo intervalo está configurado por el stagingPurgeInterval parámetro.
Las cargas fallidas (por ejemplo, debido a una interrupción de la red) se colocan en una cola de reintentos y se vuelven a intentar periódicamente. El intervalo de reintentos se configura usando el stagingRetryInterval parameter .

Configuración de la replicación sin binarios con Amazon S3

Para configurar la replicación sin binarios con S3, se requieren los siguientes pasos:
  1. Instale las instancias de creación y publicación y asegúrese de que se inician correctamente.
  2. Vaya a la configuración del agente de replicación, abriendo una página en http://localhost:4502/etc/replication/agents.author/publish.html .
  3. Pulse el botón Editar en la sección Configuración .
  4. Cambie la opción Serialización a Binario menos .
  5. Agregue el parámetro " binaryless = true " en el URI de transporte. Después del cambio, el URI debería tener un aspecto similar al siguiente:
    http://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true
  6. Reinicie todas las instancias de creación y publicación para que los cambios surtan efecto.

Creación de un clúster con S3 y MongoDB

  1. Descomprima el inicio rápido de CQ con el siguiente comando:
    java -jar cq-quickstart.jar -unpack
  2. Una vez desempaquetado AEM, cree una carpeta dentro del directorio de instalación crx-quickstart / install .
  3. Cree estos dos archivos dentro de la crx-quickstart carpeta:
    • org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService . config
    • org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore . config
    Después de crear los archivos, agregue las opciones de configuración según sea necesario.
  4. Instale los dos paquetes necesarios para el almacén de datos S3 como se explica anteriormente.
  5. Asegúrese de que MongoDB esté instalado y de que mongod se esté ejecutando una instancia de.
  6. Inicie AEM con el siguiente comando:
    java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo
  7. Repita los pasos del 1 al 4 para la segunda instancia de AEM.
  8. Inicie la segunda instancia de AEM.

Configuración de un almacén de datos compartido

  1. En primer lugar, cree el archivo de configuración del almacén de datos en cada instancia necesaria para compartir el almacén de datos:
    • Si utiliza un FileDataStore , cree un archivo con el nombre org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config y colóquelo en la <aem-install>/crx-quickstart/install carpeta.
    • Si utiliza S3 como almacén de datos, cree un archivo con el nombre o rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config en la <aem-install>/crx-quickstart/install carpeta como se indica más arriba.
  2. Modifique los archivos de configuración del almacén de datos en cada instancia para que apunten al mismo almacén de datos. Para obtener más información, consulte este artículo .
  3. Si la instancia se ha clonado desde un servidor existente, debe eliminar el clusterId de la nueva instancia mediante la herramienta de ejecución de roble más reciente mientras el repositorio está sin conexión. El comando que necesita ejecutar es:
    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    
    
    Si se configura un almacén de nodos de segmento, se debe especificar la ruta del repositorio. De forma predeterminada, la ruta es <aem-install-folder>/crx-quickstart/repository/segmentstore. Si se configura un almacén de nodos de Document, puede utilizar un URI de cadena de conexión Mongo.
    La herramienta Oak-run se puede descargar desde esta ubicación:
    Tenga en cuenta que se deben utilizar distintas versiones de la herramienta en función de la versión de Oak que utilice con la instalación de AEM. Consulte la lista de requisitos de versión que aparece a continuación antes de utilizar la herramienta:
    • Para las versiones Oak 1.2.x , utilice Oak-run 1.2.12 o posterior
    • Para las versiones de Oak más recientes que las anteriores , utilice la versión de Oak-run que coincida con el núcleo Oak de la instalación de AEM.
  4. Por último, valide la configuración. Para ello, debe buscar un archivo único agregado al almacén de datos por cada repositorio que lo comparte. El formato de los archivos es repository-[UUID] , donde el UUID es un identificador único de cada repositorio individual.
    Por lo tanto, una configuración adecuada debe tener tantos archivos únicos como repositorios que compartan el almacén de datos.
    Los archivos se almacenan de forma diferente, según el almacén de datos:
    • Para los archivos FileDataStore se crean en la ruta raíz de la carpeta del almacén de datos.
    • Para los archivos S3DataStore se crean en el bucket S3 configurado en la META carpeta.

Almacén de datos de Azure

AEM se puede configurar para almacenar datos en el servicio de almacenamiento de Microsoft Azure. Utiliza el org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config PID para la configuración.
Para habilitar la funcionalidad del almacén de datos de Azure, es necesario descargar e instalar un paquete de funciones que contenga el conector de Azure. Vaya al repositorio de Adobe y descargue la versión más reciente de las versiones 1.6.x del paquete de funciones (por ejemplo, com.adobe.granite.oak.azureblobConnector-1.6.3.zip).
Al utilizar AEM 6.4 con TarMK, los binarios se almacenan de forma predeterminada en FileDataStore. Para utilizar TarMK con el Almacén de datos de Azure, debe iniciar AEM usando el crx3tar-nofds modo de ejecución, por ejemplo:
java -jar aem6.4.jar -r crx3tar-nofds

Una vez descargado, puede instalar y configurar el conector de Azure de la siguiente manera:
  1. Extraiga el contenido del archivo zip del paquete de funciones en una carpeta temporal.
  2. Vaya a la carpeta temporal y copie el contenido de jcr_root/libs/system/install en la <aem-install>crx-quickstart/install carpeta.
  3. Si AEM ya está configurado para trabajar con el almacenamiento Tar o MongoDB, elimine los archivos de configuración existentes de la /crx-quickstart/install carpeta antes de continuar. Los archivos que deben eliminarse son:
    Para MongoMK:
    org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    Para TarMK:
    org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Vuelva a la ubicación temporal en la que se ha extraído el paquete de funciones y copie el contenido de jcr_root/libs/system/config en la <aem-install>/crx-quickstart/install carpeta.
  5. Edite el archivo de configuración y agregue las opciones de configuración requeridas por la configuración.
  6. Inicie AEM.
Puede utilizar el archivo de configuración con las siguientes opciones:
  • azureSas="": En la versión 1.6.3 del conector, se agregó compatibilidad con la firma Azure Shared Access (SAS). Si las credenciales SAS y de almacenamiento existen en el archivo de configuración, SAS tiene prioridad. Para obtener más información sobre SAS, consulte la documentación oficial . Asegúrese de que el carácter '=' tiene un carácter de escape como '\='.
  • azureBlobEndpoint="": Extremo de blob de Azure. Por ejemplo, https://<storage-account>.blob.core.windows.net.
  • accessKey="": El nombre de la cuenta de almacenamiento. Para obtener más información sobre las credenciales de autenticación de Microsoft Azure, consulte la documentación oficial .
  • secretKey="": La clave de acceso al almacenamiento. Asegúrese de que el carácter '=' tiene un carácter de escape como '\='.
  • container="": Nombre del contenedor de almacenamiento blob de Microsoft Azure. El contenedor es una agrupación de un conjunto de blobs. Para más detalles, lea la documentación oficial .
  • maxConnections="": Número simultáneo de solicitudes simultáneas por operación. El valor predeterminado es 1.
  • maxErrorRetry="": Número de reintentos por solicitud. El valor predeterminado es 3.
  • socketTimeout="": Intervalo de tiempo de espera, en milisegundos, utilizado para la solicitud. El valor predeterminado es 5 minutos.
Además de la configuración anterior, también se pueden configurar las siguientes opciones:
  • path: Ruta del almacén de datos. El valor predeterminado es <aem-install>/repository/datastore.
  • RecordLength: El tamaño mínimo de un objeto que debe almacenarse en el almacén de datos. El valor predeterminado es 16 KB.
  • maxCachedBinarySize: Los binarios con un tamaño menor o igual que este tamaño se almacenarán en la memoria caché. El tamaño está en bytes. El valor predeterminado es 17408 (17 KB).
  • cacheSize: El tamaño de la caché. El valor se especifica en bytes. El valor predeterminado es 64 GB.
  • secret: Solo se debe utilizar si se utiliza replicación sin binarios para la configuración del almacén de datos compartido.
  • stagingSplitPerpercentage: El porcentaje de tamaño de caché configurado para utilizarse en cargas asincrónicas de ensayo. El valor predeterminado es 10.
  • uploadThwords: Número de subprocesos de carga que se utilizan para cargas asincrónicas. El valor predeterminado es 10.
  • stagingPurgeInterval: El intervalo en segundos para la depuración de cargas terminadas desde la caché de ensayo. El valor predeterminado es 300 segundos (5 minutos).
  • stagingRetryInterval: Intervalo de reintentos en segundos para cargas fallidas. El valor predeterminado es 600 segundos (10 minutos).
Todas las opciones de configuración deben estar entre comillas, por ejemplo:
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Data store garbage collection

El proceso de recolección de elementos no utilizados del almacén de datos se utiliza para eliminar los archivos no utilizados del almacén de datos, lo que libera espacio valioso en el disco durante el proceso.
Puede ejecutar la recopilación de elementos no utilizados del almacén de datos mediante:
  1. Ir a la consola JMX ubicada en https://<serveraddress:port>/system/console/jmx
  2. Buscando RepositoryManagement. Una vez que encuentre el MBean del Administrador de repositorios, haga clic en él para ver las opciones disponibles.
  3. Desplácese hasta el final de la página y haga clic en el vínculo startDataStoreGC(boolean markOnly) .
  4. En el cuadro de diálogo siguiente, introduzca false para el markOnly parámetro y, a continuación, haga clic en Invocar :
    El markOnly parámetro indica si la fase de barrido de la recolección de elementos no utilizados se ejecutará o no.

Recopilación de elementos no utilizados del almacén de datos para un almacén de datos compartido

Al realizar la recopilación de elementos no utilizados en una configuración de almacén de datos agrupados o compartidos (con Mongo o Segment Tar), el registro puede mostrar advertencias sobre la incapacidad de eliminar determinados identificadores de blob. Esto sucede porque otros clústeres o nodos compartidos que no tienen información sobre las eliminaciones de ID vuelven a hacer referencia a los ID de blob eliminados en una colección de elementos no utilizados anterior. Como resultado, cuando se realiza la recolección de elementos no utilizados, registra una advertencia cuando intenta eliminar un ID que ya se eliminó en la última ejecución. Este comportamiento no afecta al rendimiento ni a la funcionalidad.
Con las versiones más recientes de AEM, la recopilación de elementos no utilizados del almacén de datos también se puede ejecutar en almacenes de datos compartidos por más de un repositorio. Para poder ejecutar la recopilación de elementos no utilizados del almacén de datos en un almacén de datos compartido, lleve a cabo los siguientes pasos:
  1. Asegúrese de que todas las tareas de mantenimiento configuradas para la recopilación de datos no utilizados del almacén de datos estén desactivadas en todas las instancias del repositorio que compartan el almacén de datos.
  2. Ejecute los pasos mencionados en Binary Garbage Collection individualmente en todas las instancias del repositorio que compartan el almacén de datos. Sin embargo, asegúrese de escribir true para el markOnly parámetro antes de hacer clic en el botón Invocar:
  3. Después de completar el procedimiento anterior en todas las instancias, ejecute de nuevo el recolector de elementos no utilizados del almacén de datos desde cualquiera de las instancias:
    1. Vaya a la consola JMX y seleccione el grano del administrador de repositorios.
    2. Haga clic en el vínculo Click startDataStoreGC(boolean markOnly) .
    3. En el cuadro de diálogo siguiente, vuelva a introducir false el markOnly parámetro.
    De este modo, se recopilarán todos los archivos encontrados con la fase de marca utilizada anteriormente y se eliminarán los demás que no se utilicen del almacén de datos.