Incoherencia en el repositorio

Buscar

Síntomas

En el archivo de registro, aparece uno de los siguientes mensajes: 
WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId -
        Unknown parent node with id ...ERROR ... failed to read bundle: ...

Causa

Estos problemas pueden tener varias causas. Las posibles causas (dependiendo de la versión de CRX) son:

La causa más común es la modificación concurrente utilizando la misma sesión. En este caso, lo más probable es que el archivo CRX error.log contenga al menos una excepción ConcurrentModificationException.

Análisis, resolución

Estos síntomas indican que el índice (y, posiblemente, también el espacio de trabajo) podría ser inconsistente.

Por lo general, el impacto de una incoherencia es bajo. Un problema es que el archivo de registro está lleno de mensajes de error debido a una incoherencia.

Tipos de incoherencias

  • Elemento secundario huérfano
    • Mensaje de error: NodeState CHILD_UUID referencias inexistentes del quid principal PARENT_UUID.
    • Mensaje de comprobación de coherencia: ConsistencyCheck: No se puede reparar: El nodo
      CHILD_UUID tiene un nodo principal desconocido:
      PARENT_UUID (ConsistencyCheck.java, line 116).
    • Solución actual: usar la consola CRX (consulte el artículo).
  • Elemento principal que hace referencia a un elemento secundario inexistente
  • Elemento secundario que hace referencia a un elemento principal no válido
    • Mensaje de error: ChildNode tiene un quid principal no válido: INVALID_PARENT_UUID (en lugar de VALID_PARENT_UUID).
    • Solución actual: usar la consola CRX (consulte el artículo).
  • Elemento principal que no hace referencia al elemento secundario existente
    • Mensaje de error: javax.jcr.ItemNotFoundException: error al crear ruta CHILD_UUID: PARENT_UUID no tiene entrada secundaria para CHILD_UUID.
    • Solución actual: usar la consola CRX (consulte el artículo).
  • Nodo existente
  • Incoherencia en el índice de búsqueda
    • Mensaje de error: WARN NodeIteratorImpl: Excepción de recuperación de nodo con UUID: 003171fe-e2e8-457b-a3af-f74eed12c1b9: javax.jcr.ItemNotFoundException: 003171fe-e2e8-457b-a3af-f74eed12c1b9.
    • Solución actual: volver a crear el índice de búsqueda o ejecutar la comprobación o corrección de coherencia del índice de búsqueda.
  • Incoherencia en la búsqueda
    • Mensaje de error: Causado por: javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496 donde org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getNode se puede ver en el seguimiento de la pila.
    • Solución actual: comprobar y corregir una coherencia del índice de búsqueda con adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix">.
  • Incoherencia relacionada con la versión
    • La pila de mensajes de error muestra que está relacionada con el código org.apache.jackrabbit.core.version.InternalXAVersionManager.
    • Solución actual: consulte este artículo.
  • Archivo no encontrado
    • Mensaje de error: ERROR TarPersistenceManager: Error al leer el paquete: [quid]: java.io.IOException: Archivo no encontrado: nnnnn (TarPersistenceManager.java, line 1194)
      java.io.IOException: Archivo no encontrado: nnnnn.
    • Solución actual: comprobar si puede encontrar ese archivo en una copia de seguridad (data_nnnnn.tar) o eliminar index_*.tar para reconstruirlo al reiniciar.

Reparación del índice de búsqueda

Las incoherencias del índice de búsqueda pueden deberse a lo siguiente:

  • Apagado no limpio del proceso Java durante una operación de escritura. Esto sería un apagado -9 en Linux o Unix y un apagado del proceso de gestión de tareas en el SO Windows
    .
  • Algunos errores más antiguos en CRX que han sido corregidos en las últimas correcciones en caliente de CQ y CRX (para CRX2.2, 2.3 y 2.4). Para evitar estos problemas, debe estar al día con las soluciones de CRX.  Si cree que no está en la última corrección, envíe un vale a soporte de Adobe para solicitar la último corrección.

Hay dos maneras de corregir las inconsistencias del índice de búsqueda:

  • Ejecutar una comprobación de consistencia del índice de búsqueda y corregir
  • Volver a crear el índice de búsqueda

Comprobar y corregir la consistencia del índice de búsqueda

Puede ejecutar una verificación de consistencia de índice al inicio. En el workspace.xml agregue dos parámetros en el elemento: <SearchIndex class="...">

<param name="enableConsistencyCheck" value="true"/>
<param name="forceConsistencyCheck" value="true"/>

Un tercer parámetro controla si los errores deben repararse o si solo deben registrarse:

<param name="autoRepair" value="false"/> <!-- default is true -->

Ejemplo

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
    <param name="path" value="${wsp.home}/index"/>
    <param name="enableConsistencyCheck" value="true"/>
    <param name="forceConsistencyCheck" value="true"/>
    <param name="autoRepair" value="true"/>
</SearchIndex>

Volver a crear el índice de búsqueda

Volver a crear el índice de búsqueda corregirá todas las inconsistencias del índice de búsqueda. Sin embargo, lleva más tiempo que la verificación y corrección de la consistencia del índice de búsqueda.  Debido a esto, tenga especial cuidado al planificar la reconstrucción de un índice de búsqueda y si no puede permitirse mucho tiempo de inactividad, considere hacer una revisión y corregirlo.

Planificación de la reconstrucción del índice

Dado que el tiempo necesario para reconstruir el índice depende de muchos factores diferentes (como el número total de nodos, el tamaño de los archivos de activos y los tipos de archivos de activos), primero debe probar la reconstrucción en un entorno sin producción. Utilizar la prueba de no producción para calcular el tiempo de una ventana de interrupción que necesitará en la producción. Los repositorios pequeños en el tamaño de 2-10GB pueden tardar de 30 minutos a 6 horas y los más grandes pueden tardar de 6 horas a 2 días.

Reconstruir el índice

Para reconstruir el índice de búsqueda, hacer lo siguiente:

  1. Parar CRX (o CQ)
  2. Hacer una copia de seguridad y eliminar los siguientes directorios del repositorio: crx-quickstart/repository/workspaces/crx.default/index/ y crx-quickstart/repository/repository/index/
  3. Ejecutar CRX (o CQ), esto iniciará la reconstrucción.  En CRX2.2 hacer un seguimiento de logs/crx/error.log y en CRX2.3 hacer un seguimiento de logs/error.log para ver el progreso.  Puede darse cuenta de que la indexación se realiza cuando la instancia CRX es accesible.

Comprobar y corregir la coherencia del Administrador de persistencia del espacio de trabajo

Si esto no ayuda e imprime errores que no se pueden reparar, es probable que los datos del espacio de trabajo sean inconsistentes.

Los administradores de persistencia pueden comprobar la consistencia del repositorio y solucionar problemas al inicio. Para permitir la verificación de consistencia y corregir problemas automáticamente, agregar los siguientes parámetros en el repository.xml y en el workspace.xml dentro de cada elemento <PersistenceManager class="...">, y reiniciar CRX.

En una instalación CQ5.2.X por defecto, estos archivos se pueden encontrar en crx-quickstart/repository/workspaces/*/workspace.xml y crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.

En CQ5.3, en el repository.xml se puede encontrar bajo crx-quickstart/repository/repository.xml en su lugar.

Ejemplo

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

En el próximo inicio se realizará una comprobación/reparación (administrador de índices o de persistencia). Una vez finalizada la comprobación de consistencia, desactive los ajustes correspondientes; de lo contrario, la comprobación de consistencia siempre se ejecuta al iniciar CRX.

Si solo está habilitado consistencyCheck, se crea un archivo inconsistentBundleIds.txt en el directorio del espacio de trabajo.

Si solo está habilitado consistencyFix, se lee el archivo inconsistentBundleIds.txt y se corrigen esos nodos. El archivo se borra si todo se puede arreglar.

Corregir inconsistencias en un cluster

Cuando se ejecuta una corrección de consistencia en un entorno agrupado, solo se debe ejecutar en un nodo del clúster. No iniciar otros nodos del clúster mientras se esté ejecutando el arreglo de consistencia. Una vez terminado, los nodos del otro cluster pueden ser iniciados.

Corrección rápida de inconsistencias

La verificación de consistencia escanea todos los nodos y por lo tanto es lenta. Para reducir el tiempo de mantenimiento, considere la posibilidad de ejecutar la comprobación de consistencia en una copia del repositorio y, a continuación, arregle los nodos que estén dañados. Para ello, siga los siguientes pasos:

  • Copiar el repositorio utilizando la función Copia de seguridad en línea
  • Ejecutar la comprobación de consistencia y corrija (como se ha descrito anteriormente) en la copia del repositorio, posiblemente en una máquina diferente
  • En el archivo de registro CRX, busque los UUIDs de los nodos corruptos
  • En el repositorio original, ejecutar la comprobación de consistencia y arregle solo en esos nodos

Para limitar la comprobación de consistencia y corregir a una lista de nodos, añadir los UUIDs de esos nodos en la opción de configuración “consistencyCheckUUIDs”:

Ejemplo

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyCheckUUIDs" value="ea9cb12f-8a8f-4820-88b1-6d1c496a07cd,741c905c-cfb0-422f-acd4-e0a9cbde46c6" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

Prevención del daño a repositorios

A partir de CRX 2.2, puede añadir este parámetro jvm al inicio de CRX/CQ5 para evitar corrupciones:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true

Si está utilizando el servidor CQSE de inicio rápido, puede añadir el parámetro a la variable JVM_OPTS, por ejemplo:

crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

o crx-quickstart/server/start (Mac y Linux):
exportar JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

Nota:

El uso de la propiedad del sistema validateheirarchy causa una ligera degradación en el rendimiento de las operaciones de guardar sesión en el repositorio.  Al planificar el uso de esta función, se sugiere que realice pruebas de carga de antemano para ver qué impacto tiene.  Esto se aplica especialmente si usted tiene una aplicación de escritura pesada.

[0] : http://dev.day.com/docs/en/crx/current/administering/tools.html#CRX20Tool

 

Nota:

Asegúrarse de desactivar la optimización del tar cuando se planifique la comprobación de consistencia para evitar la optimización del tar y la comprobación de consistencia en paralelo. 

Versiones relacionadas

1.X, 2.X

 Adobe

Obtén ayuda de forma más rápida y sencilla

¿Nuevo usuario?

Vínculos rápidos

Ver todos los planes Administrar los planes
Ver vínculos rápidos
Ocultar vínculos rápidos
Adobe MAX 2024

Adobe MAX
La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Adobe MAX

La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora
Adobe MAX 2024

Adobe MAX
La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Adobe MAX

La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Avisos legales    |    Política de privacidad en línea