2011-12-16 8 views
8

Ho Celeryd/RabbitMQ in esecuzione su una scatola Fedora, che comunica con un database MySQL in una casella separata. Ho notato che, in rare occasioni, se c'è anche il minimo problema di connessione al database MySQL (anche per pochi secondi), celeryd andrà in crash con l'errore:Ripristino di sedano da un'interruzione del database

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

e non riuscire a ricollegare anche quando il database diventa nuovamente disponibile.

Attualmente, sono costretto a riavviare manualmente il servizio celeryd per riavviare il sedano . C'è un modo più aggraziato e automatico per ripristinare da questi tipi di eventi? C'è qualche caratteristica di celeryd a aspettare tranquillamente, registrando l'OperationalError, e riconnettere invece di uscire completamente?

+1

Cosa sta utilizzando MySQL? È che stai usando il broker SQLAlchemy, collegandoti al DB MySQL? – brechin

risposta

0

Non conosco alcun modo per risolvere questo problema semplicemente utilizzando un flag di configurazione, ma si potrebbe considerare di eseguire il proprio lavoratore usando supervisore (s. http://supervisord.org).

Questo è anche menzionato nei documenti di sedici (http://celery.readthedocs.org/en/latest/tutorials/daemonizing.html#supervisord), incluso un collegamento ad alcuni file di configurazione di esempio.

+0

Lo stesso problema qui. Il sedano non fornisce una soluzione? Un demone esterno è l'unica opzione conosciuta? Nel mio caso ho due box con un'applicazione Python + Celery + RabbitMQ, che si collegano allo stesso database Google Cloud SQL usando SQLAlchemy. Alla fine ottengo in una delle macchine un Errore Operativo SQL (2013, 'Connessione persa al server MySQL durante la query') '. Nonostante gestiscano l'eccezione, i processi di lavoro di Celery vengono chiusi in entrambe le macchine, senza la registrazione di Celery. Solo RabbitMQ registra le connessioni che si chiudono improvvisamente – alecdotico

+0

Penso che questo sia un problema diverso (anche se entrambi dovrebbero essere gestiti da un sedano più robusto). Si sa che il messaggio di errore che hai citato si verifica se una connessione db è aperta troppo a lungo (potresti essere in grado di risolverlo aumentando il timeout nella tua configurazione mysql) – Jann