Pregunta

Tengo una aplicación web de frasco que usa Sqlalchemy con MySQL, y he configurado un ScopedSession (). También tengo un manejador Stardown_Request que llama a session.remove () después de que se termine cada solicitud. Por alguna razón extraña, si no se realizan solicitudes en la aplicación web por un día o más, la aplicación obtiene "OperationalError: MySQL Server se ha ido".

En mi misión de depuración, miré la lista de procesos del show y vi lo siguiente:

39817253 | sqladmin | my_host | kb_dev   | Sleep   |  174 |

El 174 es el número de segundos, la conexión de mi aplicación ha sido "dormir". Sigue contando si la aplicación no hace otra solicitud.

¡Parece que mi aplicación se aferra a la conexión a MySQL incluso después de que mi solicitud haya terminado! Y generalmente solo hay un proceso, sin importar cuántas solicitudes haga con mi aplicación, simultáneamente o no.

Mi pregunta es si es normal que la conexión sea "durmiendo" tanto tiempo. Estoy bastante seguro de que el sueño extendido está causando que MySQL corte la conexión después de un cierto tiempo de espera que a su vez está causando el error "OperationalError: MySQL ha desaparecido".

¿Fue útil?

Solución

El comportamiento predeterminado de Sqlalchemy es agrupar las conexiones dentro del motor:

http://www.sqlalchemy.org/docs/core/engines.html

http://www.sqlalchemy.org/docs/core/pooling.html

En cuanto a la desconexión de la noche a la mañana, este es un comportamiento MySQL conocido, Sqlalchemy proporciona la bandera de Pool_recycle para que funcione a su alrededor. Aquí hay muchos enlaces que lo describen:

http://www.sqlalchemy.org/docs/dialects/mysql.html#connection timeouts

http://www.sqlalchemy.org/docs/core/pooling.html#setting-pool-recycle

http://www.sqlalchemy.org/docs/core/engines.html#sqlalchemy.create_engine (Pool_recycle)

http://www.sqlalchemy.org/trac/wiki/faq#mysqlserverhasgoneaway

Publicación de blog de hace solo unos días:

http://douglatornell.ca/blog/2012/01/08/staying-alive/

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top