某虚拟化部署的服务群,发现其中一个程序在写数据库时,经常有死锁现象,一旦出现,持续时间长达数分钟。当时没时间排查,一直到年底才解决。后面又忙,直到月底才有点时间总结。抛开起初没找到问题的时间外,花了几天解决了问题,虽然没有很难的技术问题,但过程还是值得记录的。本文从后来者角度总结一下解决问题的过程,不涉及代码。
由于本文没有技术含量,请谨慎按需阅读。
起因
从前2个月开始,就收到反馈,数据上传不及时。具体表现是我负责的一个用Golang语言写的数据入库程序断续出现死锁,提示信息如下:
Error 1205: Lock wait timeout exceeded; try restarting transaction
因为有很多个服务连接同一数据库,无法定位到具体原因,排查不到问题。
排查及解决
问题定位
本节根据时间顺序结合排查结果描述解决过程。
经查,在该服务群部署之初,数据库日志就显示有几个警告,如[Warning] [MY-010055] [Server] IP address '192.18.18.168' could not be resolved: Temporary failure in name resolution
。至今也有,所以应该不是关键问题。
在出现死锁时,登录mysql,使用select * from processlist where command!='Sleep';
查看进程列表,发现我写的程序里的几条插入sql语句明显卡在那里,除此外,还有外部IP进行的select操作,还有本服务器上几个进程进行的select和update操作。
拿其它地方的服务器配置和程序版本来做对比,内存、CPU方面相差不多,自己所了解到的连接数据库的程序版本是一样的,所用的docker镜像ID也是一样的。
此时,问题排查卡住了,接着忙于其它项目,一直到年底。
元旦收假第一天上班,业主上报到领导处,上峰过问,所以必须解决。
我写的程序是入库,还有另外程序是读库传输。于是打电话咨询相关开发人员,但由于刚接不久,问不到问题。
又回到数据库列锁问题上。以个从能力水平,看不到问题,于是联系DBA寻求帮忙,DBA提到一个概念:间隙锁。上网查了一下,的确有这个概念,大意是如果有select操作,数据库会将邻近的数据记录锁住,防止幻读情况出现。前面提到,出现死锁时,数据库有insert、update、select操作,而且极可能是相同的表——因为不同程序,是通过数据库做数据中转站的。此外,DBA还说,如果在select或update过程耗时,那么极可能出现死锁,解决办法是加索引,将耗时降低。
解决方法
于是联系相关开发人员,得到程序会在某个时候进行update操作,观察其语句,是使用一个大ID和和小ID进行update的,其中匹配大ID的数据记录有数十至数百条不等(小ID只匹配一条),而update操作只是更新其中一条数据记录。但是,对大ID没有做索引。
基本定位到问题了。本来想让相关程序的开发人员进行加索引的,但个人推不动,于是直接上手到生产环境上的数据库加索引。先停止我写的程序——因为这个程序是直接写库的,再登录数据库,找到对应的表,建索引。示例语句如下:
show index from foobar;
CREATE INDEX idx_foobar_my_id_dataid_state ON laneheartbeat (my_id, dataid, state);
其中一张表数据量大,建立索引大概耗时几分钟,当时就慌了,以为出事故了,还好一切正常。
接着重启程序,观察日志,入库正常。后面观察了3天日志,都没有出现exceeded
。问题基本解决。
接着在其它服务集机器上对数据库的表都建立相同的索引。
反馈
后来了解到,在数据表建立索引的事,其实相关开发人员已经做了测试验证,性能的确提升了很多,可能担心影响,没继续进行。只是个人没想到问题的原因,没问别人,别人也没共享信息。经此事后,也加强了这方面问题的排查和知识的积累。
因为问题直接表现在我负责的程序,也因为数据库方面的确不行,所以花了几天时间。但对业主来说,从问题产生到解决,已经用了近3个月了。
小结
回顾发现,本文遇到的问题,就是数据库的索引正确建立,导致操作耗时,加上多个程序同时操作数据库,因间隙锁机制,出现死锁。建立索引即可解决。