2012-07-03 5 views
6

Tengo dos instancias de Jackrabbit que contienen el mismo contenido. Reconstruir el índice de Lucene es lento, más de 30 horas, y el tiempo de inactividad necesario en el clúster es arriesgado. ¿Es posible simplemente volver a indexar una Jackrabbit y luego copiar el índice de Lucene de esa instancia a la otra?Copiar índices de Lucene entre los repositorios de Jackrabbit

La copia ingenua de los archivos de índice de Lucene debajo del directorio de espacio de trabajo no funciona. El problema parece ser que el contenido está indexado por el número de documento que se asigna a un UUID que se asigna a la ruta JCR para el nodo indexado, pero estos UUID no son estables para una ruta determinada entre las instancias de Jackrabbit. (Ambas son en realidad instancias de editores de Day CQ pobladas por replicación de una instancia de autor de CQ).

He logrado encontrar la asignación de UUID a ruta en el repositorio en/jcr: system/jcr: versionStorage/pero No veo una manera fácil de copiar esto entre repositorios junto con el índice Lucene. Y luego no puedo encontrar el UUID-> identificación del documento en ninguna parte de los archivos. ¿Esto también forma parte del índice Lucene?

Gracias por cualquier ayuda. Me inclino por simplemente volver a indexar la segunda instancia por separado y aceptar el tiempo de inactividad, ¡pero apreciamos cualquier idea para reducir el riesgo o el tiempo transcurrido de reindexación del clúster!


Al final vamos la re-index-les-tanto de rutas: hemos conseguido reutilizar una instancia de prueba como un ejemplo vivo extra que podemos caer en la granja temporalmente mientras tomamos el otros dos a su vez para volver a indexar. Sin embargo, ¡aún estaría interesado en escuchar mejores formas de hacerlo!

+0

Eche un vistazo a esta publicación, aunque tal vez ya la haya visto. http://stackoverflow.com/questions/670182/index-replication-and-load-balancing –

+0

Gracias. No, no creo que ninguno de ellos sea relevante para mí: es el motor de búsqueda integrado, así que no puedo cambiar a Solr y al disco de otras respuestas copiando los archivos de índice, lo cual no es suficiente para mí. Necesito combinar de algún modo los datos de ruta de nodo con el índice y copiar eso, luego reconstruir la ruta -> UUID -> mapeo de número de documento en el otro, o de alguna manera transformar el índice copiado para usar los números de documento en el sistema de destino en el sistema fuente – Rup

Respuesta

2

Parece una idea aterradora, sinceramente. No estoy seguro de que haya alguna manera de garantizar que tenga los mismos datos subyacentes, incluso con contenido idéntico y configuración de hardware.

Si sus números de rendimiento se parecen a los nuestros, el tiempo para copiar todo el repositorio es menor que el tiempo que lleva reindexar. ¿Ha considerado simplemente reindexar un repositorio, hacer una copia de seguridad/copia y luego configurar la copia de seguridad/copia para que sea su segunda instancia?

+0

Gracias - no, eso no se me había ocurrido, esa es una buena idea. Sí, la sincronización de dos repositorios es más rápida que un re-index, pero cuando rsync live en una máquina de prueba siempre terminamos con algunas fallas. Nuestro repositorio es demasiado grande y no tenemos suficiente espacio de almacenamiento para intentar usar las diversas opciones de copia de seguridad y restauración de CQ, por lo que creo que deberíamos eliminar el servidor de origen de copia así como el servidor de destino de copia para intentarlo esto, y luego volvemos a una sola máquina en el clúster en vivo mientras se lleva a cabo la copia. ¡Sin embargo, correré esto más allá del equipo! – Rup

+0

Si observa cómo funciona la copia de seguridad en línea CQ, básicamente hace una serie de rsyncs. Cada iteración tiene menos para copiar y luego se bloquea en la última. He tenido mucha suerte al usar repetidos rsyncs para hacer lo mismo para copiar un servidor en ejecución. Obviamente, eso funciona mejor si el servidor que se está copiando no está viendo muchas escrituras. – lo5an

Cuestiones relacionadas