2011-12-16 12 views
8

Tengo Celeryd/RabbitMQ ejecutándose en una caja de Fedora, comunicándome con una base de datos MySQL en un cuadro separado. Me he dado cuenta de que, en raras ocasiones, si no hay ni el más mínimo problema para conectarse a la base de datos MySQL (aunque sea por unos segundos), celeryd chocará con el error:Recuperación de apio de una interrupción de la base de datos

OperationalError: (2003, "Can't connect to MySQL server on 
'mydatabasedomain' (111)") 

y no volver a conectar incluso cuando la base de datos vuelve a estar disponible.

Actualmente, estoy obligado a reiniciar manualmente el servicio apical para obtener apio funcionando nuevamente. ¿Hay alguna forma más elegante y automática de recuperar estos tipos de eventos? ¿Hay alguna característica de apliación en espere silenciosamente, inicie sesión en OperationalError y vuelva a conectar en su lugar para salir por completo?

+1

¿Qué es MySQL? ¿Es que está utilizando el intermediario SQLAlchemy, conectándose a la base de datos MySQL? – brechin

Respuesta

0

No conozco ninguna forma de solucionar esto simplemente usando una bandera de configuración, pero podría considerar ejecutar a su trabajador mediante el supervisor (s. http://supervisord.org).

Esto incluso se menciona en los documentos de apio (http://celery.readthedocs.org/en/latest/tutorials/daemonizing.html#supervisord) incluyendo un enlace a algunos archivos de configuración de ejemplo.

+0

Mismo problema aquí. ¿El apio no proporciona una solución? ¿Un daemon externo es la única opción conocida? En mi caso, tengo dos cajas que ejecutan una aplicación de Python + Celery + RabbitMQ, que se conectan a la misma base de datos de Google Cloud SQL utilizando SQLAlchemy. Eventualmente obtengo en una de las máquinas un SQL OperationalError '(2013, 'Conexión perdida al servidor MySQL durante la consulta')'. A pesar de manejar la excepción, los procesos de trabajo de apio se cierran en ambas máquinas, sin el registro de apio. Solo RabbitMQ registra las conexiones cerrando abruptamente – alecdotico

+0

Creo que este es un problema diferente (aunque ambos deberían manejarse con un apio más robusto). Se sabe que el mensaje de error que citó ocurre si una conexión db está abierta demasiado tiempo (es posible que pueda solucionarlo aumentando el tiempo de espera en su configuración de mysql) – Jann

Cuestiones relacionadas