背景
我们来先看一个图,了解一下故(事)事(故)的背景:
有2
个跑批任务,其实做的事情是同一件事情,都是为了跟下游系统保持数据的一致性。大任务是每个2h
跑一次,小任务是每隔10mins
跑一次。除了这2
个定时任务以外,还有一个额外的监控任务来做类似的对账,如果发现出现对账不平,就会出现邮件/短信告警到相关的责任上。
这是一个非常有特点的定时任务跑批任务+监控告警的场景了。
从上面的场景上看,我们可以得出一些结论:为了保证一致性写了大小Job来保证,并且还给出了监控告警,说明数据的重要性是比较强的。
某天,出现了频繁的告警提示,每10
分钟就告警一次,而且内容没有发生变化,说明同步的index
没有变化过。
错误排查
任务有在正常的执行吗?
第一反应肯定是在思考,我的大任务与小任务都有正常执行吗?因为之前的都是正常的。上午看了一下日志与进程发现有在跑,还跑除了多次任务,日志打印不明确,看不到具体分支的逻辑。总结一下问题点:
- 任务很忌讳出现上一个任务没有跑完,下一个任务又继续开启一个新的任务,给服务器带来了不少的压力。一般如果对接了好的分布式调度能力,基本也很容易客服这个问题。
- 关键分支日志打印不明确,导致定位很难
先修复上面2
个问题,短时间对接一个新的分布式调度时间上不可能,只能简单的改shell
脚本让其不执行。
1 | d=`date` |
然后在重点的地方添加上日志,其实这些操作都是一些非常简单,但是可以带来明显效果的步骤。反正,我基本都是如此的去做的,你什么信息都拿不到,你根本无法入手。
部署上去后,发现每次在insert into
一条数据的时候,日志就卡住了,结合代码确定,确定就是insert into
的时候,数据库没有返回,而其他的表以及其他数据的都是可以正常操作的。
出现了LOCK WAIT
第一反应,就是看下这条SQL
现在是一个什么状态?我们可以利用SHOW PROCESSLIST
看下
1 | select * from information_schema.PROCESSLIST t; |
然后就发现该SQL
语句的trx_state=LOCK WAIT
,那说明没有获取到锁。那我们具体如何推断是谁没有释放锁了?
1 | 第1步: |
可惜,那条语句已经是sleep
的状态了,无法看到具体的SQL
。在这里可以推断,就是有一条SQL
在对数据{local_data}
操作的时候获取了一把锁,但是因为事务未提交,导致后面的SQL
再对{local_data}
操作的时候要获取锁,无法获取到。理论上获取不到锁,一会儿也会释放掉报错出来。通过查询innodb_lock_wait_timeout=7200
,默认值应该是50
。
解决掉问题
到这一步就很明确了,就是让未提交事务的SQL
结束掉,或者提交掉。此时只有kill
掉这个进程的选项了。执行:
1 | kill {lock_trx_id}; |
再执行就立马发现数据没有了,获取到了锁。
1 | SELECT * FROM information_schema.innodb_trx t where t.trx_state = 'LOCK WAIT'; |
总结一下
innodb_lock_wait_timeout
设置不合理,时间太久了- 出现获取不到锁的场景,需要告警到邮件、手机上来。
- 大任务与小任务的时间要搓开,出现这种情况也是对同一行数据进行X操作并且未释放锁导致的。把事务的时间搞短一点。可以每次都去获取连接,也不要一次连接执行很长时间。
实验性操作
就直接看脚本好了
当右边的事务对同一条数据进行X操作的时候,它是要获取锁的。
1 | ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction |
这个时候可以去看下锁的表
1 | select * from information_schema.innodb_locks; |
查看一下设置的超时时间
1 | show variables like 'innodb_lock_wait_timeout'; |
看关于事务的描述
1 | show engine innodb status |
查看当前的事务
1 | mysql> show processlist; |
参考地址
如果大家喜欢我的文章,可以关注个人订阅号。欢迎随时留言、交流。如果想加入微信群的话一起讨论的话,请加管理员微信号:chengcheng222e
,他会拉你们进群。