本文主要是介绍Python捕捉MySQL的警告导致的事物锁等待超时问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
当有多个进程相对高并发的读取删除数据库的时候,经常会出现事物锁锁死,导致锁等待时间超时的致命错误。
翻看日志,可以查看到最早出现的是以下错误
InternalError(1205, 'Lock wait timeout exceeded; try restarting transaction')
但是该错误提示仅仅出现了几次,之后会不断的出现下面的错误提示
OperationalError(2013, 'Lost connection to MySQL server during query')
到最后就干脆变为
InterfaceError("(0, '')",)
对于数据库的了解并不深,一开始以为就是MySQL无法承受高并发,但是感觉MySQL应该没那么弱。
翻阅了MySQL的日志之后,可以看到以下警告和错误信息
2017-12-01T09:42:11.954799Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2017-12-01T09:42:11.954862Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
2017-12-01T09:42:12.191029Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2017-12-01T09:42:15.371812Z 0 [ERROR] /usr/sbin/mysqld: Table './mysql/user' is marked as crashed and should be repaired
2017-12-01T09:42:15.372197Z 0 [Warning] Checking table: './mysql/user'
2017-12-01T09:42:15.372222Z 0 [ERROR] 1 client is using or hasn't closed the table properly
2017-12-01T09:42:15.421626Z 0 [ERROR] /usr/sbin/mysqld: Table './mysql/db' is marked as crashed and should be repaired
2017-12-01T09:42:15.421836Z 0 [Warning] Checking table: './mysql/db'
2017-12-01T09:42:15.421850Z 0 [ERROR] 1 client is using or hasn't closed the table properly
看着这错误提示,感觉也是很莫名其妙了。并没有打开很大量的文件丫。一条一条Google下去之后也没有找到任何有效的解决信息。
此时回顾该错误,锁等待超时,说明发现了死锁。但是代码中对于数据库的调用,并不会存在任何的死锁问题,互相是不干扰的丫。
好一阵思考之后,感觉可能是,执行了某个SQL
语句,但是该语句并没有提交过去,所以卡住了。
之后再去看代码,发现我为了能够捕捉到警告,将SQL
的warning
提升为了错误
from warnings import filterwarnings
filterwarnings('error', category=pm.Warning)
我这时候就意识到是这里的问题了。
对于MySQL的警告,尽管有警告,但还是能够顺利正常的运行的。然而我直接将其捕捉打印了出来,恰恰缺少了commit
。
所以问题应该就出在这里,所以修改了一下代码。在捕捉警告之前先commit
一下。这时发现数据库不会再挂掉了。
这篇关于Python捕捉MySQL的警告导致的事物锁等待超时问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!