¿Es extraño que mi conexión SQLAlchemy MySQL siempre termine durmiendo?

Question

Tengo una aplicación web Flask que utiliza SQLAlchemy con MySQL, y he configurado una scopedsession(). También tengo un controlador teardown_request que llama a session.remove() después de finalizar cada solicitud. Por alguna extraña razón, si no se realizan solicitudes en la aplicación web durante un día o más, la aplicación obtiene "Operationalerror: MySQL Server se ha ido".

En mi misión depuración, miré SHOW PROCESSLIST y vieron los siguientes:

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

El 174 es el número de segundos que la conexión de mi solicitud haya sido "durmiendo". Sigue contando si la aplicación no realiza otra solicitud.

Parece que mi aplicación se aferra a la conexión a MySQL incluso después de que mi solicitud haya finalizado. Y generalmente hay solo 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 esté "durmiendo" tanto tiempo? Estoy bastante seguro de que la suspensión prolongada está haciendo que MySQL corte la conexión después de un cierto tiempo de espera que a su vez está causando el error "OperationalError: Mysql se ha ido".

Answer 1

comportamiento predeterminado de SQLAlchemy es agrupar conexiones dentro del motor:

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

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

En cuanto a la cosa durante la noche de desconexión, este es un comportamiento MySQL conocido, SQLAlchemy ofrece la bandera pool_recycle a trabajar a su alrededor. Aquí hay muchos enlaces que describen que:

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

Blog post de hace tan sólo unos días:

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