搜公众号
推荐 原创 视频 Java开发 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库
Lambda在线 > shysheng > 一次线上Mysql死锁引发的血案

一次线上Mysql死锁引发的血案

shysheng 2019-01-18
举报

嗯,首先承认,做了回标题党(另外也是因为确实没想到更好的标题,求轻拍)。由于修复及时,最终并没有对线上用户产生任何影响,血案也并没有发生。

工作三年半了,第一次碰到了mysql死锁,老实说当时还挺开心的😆

1.案件回顾

去年平安夜,笔者参与的一个项目如期上线。作为一名老司机,一切都是那么轻车熟路。发布完成的那一刻,嘴角不自觉浮起了一丝不易察觉的微笑,然而我不知道的是,危险正在一步步靠近。

在随后QA同学和产品同学的线上验收过程中,发现有极高的概率会出现支付失败的场景。从当时的日志来看,这是由于数据库死锁引起的,如下图所示:


案发现场死锁日志.png

预发环境验证得好好的,为什么一到线上就会有极高的概率出现死锁呢?笔者仔细分析了出现死锁的sql,发现在上线前对该sql有微小的改动,当时也是为了修复一个有极低概率出现的问题。只是当时修改以后只对相关流程进行了一次验证,而刚好那一次没有出现死锁,所以这个有问题sql就这样被错误地发布到了线上环境。

作为一个美业SAAS产品,开单支付链路是绝对的核心场景,保证该流程的稳定是一等一的大事。考虑到短时间内彻底定位修复该问题不太现实,为了保证线上环境的稳定,笔者当时紧急对这个有问题的sql进行了回滚,由于当时已接近午夜,再加上发布的是一个新功能,所以并没有对线上用户造成任何影响,笔者就这样与一场血案擦肩而过...

线上问题处理首要原则:第一时间解决问题,保留现场事后分析。

2.案情分析

第二天一早,笔者迫不及待仔细分析了日志,找到了发生死锁的两个事务,相关sql简化处理后如下,事务隔离级别为RC:
事务1:

update 
table_name 
set colume1 = 2 
where kdt_id = 6666 and 
order_no = 'M1' and 
pay_no = 'P1' and 
colume1 in (1, 2, 3) limit 1;

事务2:

update 
table_name 
set colume1 = 3 
where kdt_id = 6666 and 
order_no = 'M1' and 
pay_no = 'P1' limit 1;

其中表table_name的索引信息如下:

  PRIMARY KEY (`id`),
  KEY `idx_kdt_order` (`kdt_id`,`order_no`),
  KEY `idx_payno_kdt` (`pay_no`,`kdt_id`),
  KEY `idx_kdt_asset_detail_no` (`kdt_id`,`asset_detail_no`)

同时查看两个update语句的执行计划,发现二者走的是同一个idx_payno_kdt这个二级索引。既然走的是同一个二级索引,按照常规加锁套路,mysql会首先对这个二级索引加锁,然后对主键加锁。两个sql的加锁顺序应该完全一样,既然如此,何来死锁?此时,笔者陷入了漫长的沉思。

3.连环作案?

毕竟是第一次处理死锁案例,几天下来毫无进展。正当我手足无措之时,一封告警邮件映入眼帘。笔者如炬的目光被那个熟悉的朋友给深深地吸引住了——DeadLock。我勒个乖乖,还是个连环案啊。有意思了,二话不说,先拿到触发死锁的sql。
事务1:

UPDATE 
table_name
SET`asset_detail_no`='xx',`ext_pay_info`='xx'`updated_at`='2019-01-02 17:02:57'where 
`kdt_id`=6666 and `order_no`='M1' and `pay_no`='P1' limit 1;

事务2:

UPDATE
table_name
SET`pay_result`=1,`pay_status`=3,`updated_at`='2019-01-02 17:02:57'where 
`kdt_id`=6666 and `order_no`='M1' and `pay_no`='P1' limit 1

同样,两个update语句都走的是idx_payno_kdt这个二级索引。同时由于上一次的经验,这次马上联系DBA拿到了死锁日志:

------------------------
LATEST DETECTED DEADLOCK
------------------------2019-01-02 17:02:57 0x7f8ed339d700*** (1) TRANSACTION:TRANSACTION 154905880096, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 10519814, OS thread handle 140251427940096, query id 37831367279 10.96.0.7 beauty updating
UPDATE
        table_name
        SET        `asset_detail_no`='xx',        `ext_pay_info`='xx',        `updated_at`='2019-01-02 17:02:57'
        where `kdt_id`=6666 and `order_no`='M1' and `pay_no`='P1' limit 1*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 3208 page no 28442 n bits 112 index PRIMARY of table `db_name`.`table_name` trx id 154905880096 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:TRANSACTION 154905880094, ACTIVE 0 sec starting index read, thread declared inside InnoDB 5000mysql tables in use 1, locked 15 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 10521136, OS thread handle 140251405866752, query id 37831367285 10.96.0.16 beauty updating
UPDATE        `table_name`
        SET        `pay_result`=1,        `pay_status`=30,        `pay_at`='2019-01-02 17:02:57',        `updated_at`='2019-01-02 17:02:57'
        where `kdt_id`=6666 and `order_no`='M1' and `pay_no`='P1' limit 1*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 3208 page no 28442 n bits 112 index PRIMARY of table `db_name`.`table_name` trx id 154905880094 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 3208 page no 28233 n bits 160 index idx_payno_kdt of table `db_name`.`table_name` trx id 154905880094 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)

有了死锁日志,很多东西都一目了然,其作用简直堪比车祸现场的行车记录仪啊!

从以上死锁日志中我们可以看到死锁究竟是如何发生的:
事务1在等等表的主键锁,而事务2持有主键锁,在等待二级索引idx_payno_kdt上的锁。既然发生了死锁,说明事务1应该是持有了idx_payno_kdt的锁(但是这个在死锁日志中并无记录),从而导致两个事务互相等待对方持有的锁。

4.案件合并

虽然两次死锁发生的sql语句并不完全一样,但都是因为两个事务对同一张表进行update引起的。而且由于show engine innodb status只能记录最近一次发生的死锁,所以我们对第一次死锁已无法拿到更多现场信息。再结合业务场景,笔者决定对两案合并一案进行分析。

线上死锁定位首要原则:第一时间拿到死锁日志协助分析。

在案件2中,我们目前最大的疑问是:事务2怎么拿到主键锁的?是因为发生了index_merge优化吗(具体可参考index_merge引发的死锁排查)?
但是通过查看执行计划,我们发现两个update语句执行计划中的type值都是range,即都没有走index_merge优化,此路不通😔

既然跟index_merge没有关系,还有什么情况可能会导致事务2持有主键锁呢?笔者再次陷入了沉思...

在整个案件的分析过程中,笔者其实一直在跟DBA保持沟通(一个会做饭的暖男,技术很牛逼,积累了很多定位线上mysql问题的经验并以博客形式输出,传送门:For DBA)。期间DBA的一个思路给了我启发,他说因为表table_name中存在多个二级索引,在where条件中,order_no和pay_no分别是两个二级索引中的字段,有可能是在某种条件下,事务2先走了idx_kdt_order索引,从而通过该索引拿到了主键锁。

然而事务2的执行计划清清楚楚明明白白地告诉我们,该update语句只走了idx_payno_kdt这个一个二级索引,那么可能会有什么场景触发其先走idx_kdt_order这个索引呢?

哦对了!笔者突然灵光一现,死锁日志只会记录发生死锁的sql语句,但是一个事务中可能会有多个sql语句,在发生死锁之前的sql语句都不会被记录到死锁日志中!

想到这一点,笔者隐隐感觉真相越来越近了。由于对案件分析已经断断续续持续了10来天,我不用继续翻代码都知道事务2在执行update语句之前还执行了一个select语句,并且刚好走了idx_kdt_order这个索引,该select语句如下:

select * from 
table_name 
where 
kdt_id=6666 and order_no=‘M1' and pay_status in (3, 5) for update;

在该语句中,事务2会通过idx_kdt_order这个二级索引持有主键锁,这就完美地解释了我们之前的疑问。正是这个select ... for update语句的存在,导致了两个事务的加锁顺序发生了不一致,从而引发死锁。
我想,案发现场当时的情况应该是这样的:


image.png

5.真相大白?No!

至此,案情似乎真相大白了,罪魁祸首正是这个select ... for update语句。然而,事实果真如此吗?

在跟DBA的沟通过程中,笔者还得到一个信息就是,在RC隔离级别下,针对select ... for update语句,如果最终返回结果集为空,那么mysql会对此进行了一些优化,加上的X锁会提前释放(详细分析可参考MySQL加锁处理分析)。

本着实践出真知的原则,笔者在本地mysql对此进行了验证,其中t1与线上环境发生死锁的table_name完全一致,且满足kdt_id=6666 and order_no='M1'条件的记录有两条,但它们的pay_status状态都不是30或者50,也就是说,事务1返回的结果集为空。
事务1:

begin;
select * from order_t1 where kdt_id=6666 and order_no='M1' and pay_status in (30, 50) for update;

事务2:

begin ;
UPDATE
t1
SET`updated_at`='2019-01-02 17:02:57'where `kdt_id`=6666 and `order_no`='M1' and `pay_no`='P1' limit 1;

先执行事务1,再执行事务2,在RR级别下,事务2确实会被阻塞,但是在RC级别下却不会。

这也完美映证了DBA的说法,针对select ... for update语句,在RC隔离级别下,如果返回结果集为空,那么针对行记录加上的X锁会被提前释放,不会阻塞其它事务加锁。

既然会提前释放,那么案例2中,事务2又是如何获得X锁的呢?真相似乎近在眼前,却又远在天边😔

不过到了这里,案例2虽然依然疑点重重,案例1却似乎柳暗花明了。因为在案例1中,事务2的update之前也有一个类似的select... for update语句如下:

select * from order_t1 where kdt_id=6666 and order_no='M1'  for update;

只不过与案例2的相比,where条件中没有使用pay_status字段进行过滤,也就是说这个语句的结果集不为空!那么对于案例1来说,事务2在执行udpate语句之前就真的会通过idx_kdt_order持有主键锁,从而触发死锁!

6.真相?吾将上下而求索

到了这里,离第一次出现死锁已过去差不多两个星期,案例1已真相大白,但案例2却依然存疑。

因此笔者决定,要是年会之前还没有水落石出,就打飞的过去活捉DBA现场结对编程😆待真相大白后再来跟小伙伴们分享


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《一次线上Mysql死锁引发的血案》的版权归原作者「shysheng」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注shysheng微信公众号

shysheng微信公众号:gh_43ae0ad5344c

shysheng

手机扫描上方二维码即可关注shysheng微信公众号

shysheng最新文章

精品公众号随机推荐

举报