A principios de 2010, luego de haber tenido numerosos problemas con los índices de zebra (que se traducía en errores fatales en los resultados de las búsquedas) nos pusimos en contacto con los desarrolladores de Koha. El problema radicaba en el daemon zebraqueue-daemon y nos recomendaron dejar de utilizarlo de manera urgente. No queda ni quedó claro por que esta recomendación no se traduce en una actualización de la documentación ni en la definitiva eliminación del script.

Organización de la información en Koha

En una instalación de Koha utilizando zebra existen dos bases de datos paralelas:

• La base de datos relacional (MySQL o PostgreSQL)
• Zebra, motor de búsqueda de texto completo.

La base de datos relacional mantiene toda la información de la lógica de negocios de Koha, y distribuida en varias tablas, toda la información de los registros bibliográficos y de autoridad.
Especificamente, en la tabla biblioitems se almacena en el campo marcxml el registro MARC de cada título, con la información de los ejemplares (952).

Zebra lo que hace es indexar este campo para todos los registros de la base.

El problema

Cada vez que un registro es modificado es necesario avisarle a Zebra que tiene que actualizar los índices. Esto se hace en varias situaciones:

• Se agrega un título.
• Se agrega una autoridad.
• Se modifica un registro (bibliográfico o de autoridad).
• Se agregan existencias (ejemplares/items) a un título existente.
• Se circula un ejemplar…

Los puntos suspensivos del último caso deberían dar una pista del problema: Como la información de disponibilidad de los ejemplares aparece en los resultados de la búsqueda, es almacenada en el campo marcxml y por lo tanto debe ser reindexada.

Como el reindexado es una rutina realizada por una aplicación externa a koha (el comando zebraidx) hay situaciones en las que si no se hacen muy cuidadosamente los controles se da el caso de registros que no son reindexados y provocan los mensajes de error mencionados antes.

El script zebraqueue-daemon tenía varios problemas de este tipo.

Solución (a medias)

Cuando consultamos a la gente de Koha en el IRC, ellos nos dijeron que la forma correcta de mantener actualizados los indices es a través de la ejecución a través de cron del script rebuild_zebra.pl. Así lo implementamos:

En el archivo /etc/cron.d/koha
*/1 * * * * koha KOHACONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null

La solución recomendada tiene dos problemas importantes para nosotros:

• El intervalo de 1 minuto, el mínimo permitido por cron, dificulta la catalogación con autoridades.
• Lanzar un nuevo proceso Perl de a intervalos tan cortos significa una carga muy grande (e inútil) en servidores con muchas instancias de koha corriendo simultaneamente.

La solución que implementamos y compartimos

Decidí reescribir el script zabraqueue-daemon de manera que haga las tareas del cron de a intervalos mas pequeños, y además escribirlo en perl de una manera que no lance un nuevo proceso del intérprete Perl por cada corrida.

Para la reescritura utilicé el módulo POE de Perl, e hice una refactorización del script rebuild_zebra.pl como librería. El resultado fue enviado a Koha y espera su aceptación para inclusión en el Trunk. Lo comparto por esta vía.

Hay que descargar este archivo y descomprimirlo en el directorio de nuestro koha. Recomiendo descomprimirlo en cualquier otro lugar, revisar los archivos que contiene, y después copiarlos a la carpeta de Koha. Reescribirá dos archivos originales de Koha.

Para dejar corriendo el nuevo zebraqueue-daemon editar el archivo bin/koha-zebraqueue-ctl.sh de manera que refleje los directorios y base de datos de nuestro koha. Después de eso seguir los pasos usuales para hacer que sea un servicio al inicio en nuestro Linux, como se indica en los archivos INSTALL.* que vienen con el instalador.

Los intervalos de actualización que implementa el script son por defecto de 10 segundos para autoridades y 1 minuto para registros bibliográficos. No obstante, se pueden utilizar las siguientes variables de configuración de uso local (que deben agregarse en las preferencias, con «Nueva preferencia») para controlar los intervalos:

• authUpdateRatio:  Número que multiplicado por 10 da la cantidad de segundos entre actualización (por ejemplo 1 daría un intervalo de 10 segundos)
• biblioUpdateMinutes:  Cantidad de minutos entre actualización.

UPDATE: A pedido de Pablo completo este post con nueva información. Haciendo todo lo que faltaba a último momento para que el zebraqueue daemon fuera incluido en el lanzamiento de 3.4 cometí un error en la definición de las preferencias que utilizaría el daemon. Por lo tanto fue rechazada su inclusión y postergada hasta 3.6.

Fue una mala noticia, pero al menos recibimos un buen feedback de este esfuerzo realizado. En la U.N.C. lo estamos utilizando en producción sin ningún tipo de inconvenientes.