​​​​​​​​SQLAlchemy报错“2006, MySQL server has gone away”

来源:互联网 发布:js调用支付宝支付 编辑:程序博客网 时间:2024/05/18 14:44

SQLAlchemy报错“2006, MySQL server has gone away”

遇到sqlalchemy mysql server has gone away错误起初,还真难理解这是为何。按道理sqlalchemy应该有管理好自己的连接池,而且是当服务运行一段时间才报这样的错误。

搜索了一把,得知应该设置一个连接池回收时间pool_recycle,看了下flask-sqlalchemy是有默认设置为7200,sqlalchemy官方也是这么推荐的。

设置过后,运行一段时间,仍然有报类似的错误,仔细查看flask-sqlalchemy源码,发现作者在flask的每次请求完成之后,都对session连接回收了.... 

于是,tornado里,需要在继承tornado.web.RequestHandler子类的on_finish里设置db.session.remove()

而且此方法只在tornado2.2版本中才开始支持。so...低版本就升级吧!

今天上班时,突然发现测试环境登录时出错,查看gunicorn日志,显示“OperationalError: (OperationalError) (2006, 'MySQL server has gone away') 'SELECT 。。。”,其他含数据库操作的URL也是同样错误。
直接登录MySQL没有问题。重启gunicorn后登录正常。

从现象分析,应该是WEB服务器中的数据库连接不存在了,在Google上找到相应的答案。
首先,查看数据库的连接超时参数:

mysql> show variables like '%timeout';

+----------------------------+-------+

| Variable_name | Value |

+----------------------------+-------+

| connect_timeout | 10 |

| delayed_insert_timeout | 300 |

| innodb_lock_wait_timeout | 50 |

| innodb_rollback_on_timeout | OFF |

| interactive_timeout | 28800 |

| net_read_timeout | 30 |

| net_write_timeout | 60 |

| slave_net_timeout | 3600 |

| table_lock_wait_timeout | 50 |

| wait_timeout | 28800 |

+----------------------------+-------+

interactove_timeout表示当没有数据库请求时,28800秒(即8小时)将自动断开连接。刚好昨晚到今天超过8小时了,应该就是这个问题了。但SQLAlchemy的连接池是如何管理连接的呢?
SQLAlchemy在创建engine时,有一个参数:pool_recycle表示多长时间重新进行数据库连接。默认-1表示不进行连接,因此只需要将该参数修改比mysql数据库的超时设置小即可,这里设置pool_recycle为7200(2小时)

在查看SQLAlchemy配置参数时还发现另外两个参数:
pool_size=5 连接数大小,默认为5,正式环境该数值太小,需根据实际情况调大
max_overflow=10 超出pool_size后可允许的最大连接数,默认为10

http://hi.baidu.com/limpid/item/e37c37ffd12a0d11ff35825d?qq-pf-to=pcqq.c2c


0 0
原创粉丝点击