2010-03-23 2 views
12

Solr 1.4 Enterprise Search Server recomienda realizar grandes actualizaciones en una copia del núcleo y luego cambiarlas por el núcleo principal. Estoy siguiendo estos pasos:¿Cómo creo un núcleo de solr con los datos de uno existente?

  1. Crear núcleo de preparación: http://localhost:8983/solr/admin/cores?action=CREATE&name=prep&instanceDir=main
  2. Realizar actualización del índice, a continuación, confirmar/optimizar el núcleo de preparación.
  3. Intercambiar principal y preparación del núcleo: http://localhost:8983/solr/admin/cores?action=SWAP&core=main&other=prep
  4. Unload núcleo de preparación: http://localhost:8983/solr/admin/cores?action=UNLOAD&core=prep

El problema que estoy teniendo es, el núcleo creado en el paso 1 no tiene ningún dato en ella. Si voy a hacer un índice completo de todo y el fregadero de la cocina, estaría bien, pero si solo quiero actualizar un subconjunto (grande) de los documentos, obviamente eso no va a funcionar.

(podría fusionar los núcleos, pero parte de lo que estoy tratando de hacer es deshacerse de los documentos eliminados sin tratar de hacer una lista de ellos.)

¿Hay alguna bandera a la acción create que me estoy perdiendo? El Solr Wiki page for CoreAdmin es un poco escaso de detalles.

Posible solución: Replicación

Alguien en Solr usuario sugirió el uso de la replicación. Para utilizarlo en este escenario (a mi entender) requieren los pasos siguientes:

  1. Crear un nuevo núcleo PREP con sede fuera de la configuración del núcleo PRINCIPAL
  2. Cambiar la configuración del núcleo principal para ser un maestro
  3. Cambiar la configuración del núcleo PREP para que sea un esclavo
  4. Causa/¿espera una sincronización?
  5. cambie la configuración del núcleo PREP para que deje de ser un esclavo
  6. Realice una actualización de índice, luego confirme/optimice en el núcleo PREP.
  7. PREP Intercambiar y núcleos PRINCIPALES

Una configuración más simple basada en la replicación sería configurar un núcleo PREP permanente que es siempre el maestro. El núcleo MAIN (en tantos servidores como sea necesario) podría ser un esclavo del núcleo PREP. La indexación podría ocurrir en el núcleo de PREP tan rápido o tan lento como sea necesario.

Posible solución: PREP Permanente núcleo y de doble actualizar

Otra idea que se me ocurrió fue esto (también involucra un núcleo PREP permanente):

  1. Realizar actualización del índice, a continuación, confirmar/optimizar el Núcleo PREP.
  2. Cambie los núcleos PREP y MAIN.
  3. Vuelva a realizar la actualización del índice, luego confirme/optimice en lo que ahora es el núcleo de PREP. Ahora tiene los mismos datos que el núcleo MAIN (en teoría) y estará disponible, listo para la próxima operación de índice.
+0

Creo que el procedimiento está destinado a reindexar todo. ¿Qué estás usando para indexar? DIH o un proceso personalizado? –

+0

Un proceso personalizado. – stannius

+0

¿ha intentado simplemente actualizar los documentos en el mismo núcleo? realmente funciona tan mal? –

Respuesta

3

Creé esta idea de operación de clonación que hace una copia del sistema de archivos de los índices y datos de configuración, y luego CREA uno nuevo. Hay algunos problemas de bloqueo y debe tener acceso al sistema de archivos para los índices, pero funcionó. Esto le da una buena copia que puede ensuciar con los archivos de configuración.

Cuanto más pienso en ello, podría crear un nuevo núcleo y luego hacer esto:

forzar un fetchindex en el esclavo de orden maestra: http://slave_host:port/solr/replication?command=fetchindex Es posible pasar el atributo extra 'masterUrl' u otro atributos como 'compresión' (o cualquier otro parámetro que se especifica en la etiqueta) para hacer una replicación única desde un maestro. Esto obvia la necesidad de hardcoding el maestro en el esclavo.

Y llene la nueva de la de producción, luego aplique sus actualizaciones y luego vuelva a cambiar.

Cuestiones relacionadas