今年上班第一天就遇到了生产事故~跟大家分享下处理流程。
故障表现:
1.数据库连接数持续升高;
2.show engine innodb status卡死;
3.数据库服务器cpu负载很低空闲98%-100%。内存正常;
4.errorlog中没有异常信息;
5.应用全部hang住,无法打开正常页面。
排查流程:
1.首先想到show engine innodb status,结果数据库无法输出。
2.查看数据库中的正在处理的transcation,发现数据库中的长事务特别多(敏感起见数据库,用户屏蔽掉了)
有1300+的事务在running状态,同时后续数据库有新的请求进来
3.初步怀疑是数据库中的长事务导致数据库锁异常,锁请求没有释放导致后续的程序异常。zabbix中的锁信息:
4.手工kill掉长事务进程,发现这个时候数据库已经不能正常释放连接数了,而新的请求还在不断的加多。数据库连接数已经涨到1600+。
5.由于业务方压力,只能强行重启数据库释放资源后问题暂时解决。
问题复现:
暂时解决的问题肯定会复现的!果然在数据库重启后长事务又出现了。这次通过查询数据库中的长事务
发现数据库中14:05的时候出现了异常链接,同时应用报锁超时错误。通过查看事务等待可以发现801事务阻塞了后续的update请求
同时innodb的状态信息可以看到该异常事务锁住了20行记录。
手工kill掉进程后,程序恢复正常。
后续解决方案:
1.生产环境中用到的是mariadb10.0.28,其中的xtradb有针对异常transcation kill的参数。
通过设置SET GLOBAL innodb_kill_idle_transaction=60; 可以将空闲超过60秒的异常事务杀死来防止后续的锁争用和数据库挂起的问题。
2.同开发人员沟通,发现代码中存有bug。在进行异常处理的时候没有针对所有的exception进行rollback操作,而只是针对一种异常抛出错误并进行rollback。
因此程序在其他异常的时候没有及时告诉数据库进行rollback或者commit结束该事务,而是程序直接异常退出造成数据库链接处于running状态。该状态会一直持有请求的锁、内存等资源,在并发量大的情况非常容易造成数据库的挂起假死状态。改代码!
3.在zabbix中监控locking信息,超过10000ms及时报警。