一次诡异的线上数据库的死锁问题排查过程数据库

来源:互联网 / 作者:SKY / 2019-04-15 18:14 / 点击:
前几天,线上发生了一次数据库死锁问题,这一问题前前后后排查了比较久的时间,这个过程中自己也对数据库的锁机制有了更深的理解。本文总结了这次死锁排查的全过

一次诡异的线上数据库的死锁问题排查过程

前几天,线上发生了一次数据库死锁问题,这一问题前前后后排查了比较久的时间,这个过程中自己也对数据库的锁机制有了更深的理解。本文总结了这次死锁排查的全过程,并分析了导致死锁的原因及解决方案。希望给大家提供一个死锁的排查及解决思路。

本文涉及到MySQL执行引擎、数据库隔离级别、Innodb锁机制、索引、数据库事务等多领域知识。前车之鉴,后事之师,希望读者们都可以有所收获。

1、现象

某天晚上,同事正在发布,突然线上大量报警,很多是关于数据库死锁的,报警提示信息如下:

{"errorCode":"SYSTEM_ERROR","errorMsg":"nested exception is org.apache.ibatis.exceptions.PersistenceException:  

Error updating database. Cause: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL]  

Deadlock found when trying to get lock;  

The error occurred while setting parameters\n### SQL:  

update fund_transfer_stream set gmt_modified=now(),state = ? where fund_transfer_order_no = ? and seller_id = ? and state = 'NEW' 

通过报警,我们基本可以定位到发生死锁的数据库以及数据库表。先来介绍下本文案例中涉及到的数据库相关信息。

2、背景情况

我们使用的数据库是Mysql 5.7,引擎是InnoDB,事务隔离级别是READ-COMMITED。

数据库版本查询方法:

select version(); 

引擎查询方法:

show create table fund_transfer_stream; 

建表语句中会显示存储引擎信息,形如:ENGINE=InnoDB

事务隔离级别查询方法:

select @@tx_isolation; 

事务隔离级别设置方法(只对当前Session生效):

set session transaction isolation level read committed

PS:注意,如果数据库是分库的,以上几条SQL语句需要在单库上执行,不要在逻辑库执行。

发生死锁的表结构及索引情况(隐去了部分无关字段和索引):

CREATE TABLE `fund_transfer_stream` (  

  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键'

  `gmt_create` datetime NOT NULL COMMENT '创建时间'

  `gmt_modified` datetime NOT NULL COMMENT '修改时间',  

  `pay_scene_name` varchar(256) NOT NULL COMMENT '支付场景名称',  

  `pay_scene_version` varchar(256) DEFAULT NULL COMMENT '支付场景版本'

  `identifier` varchar(256) NOT NULL COMMENT '唯一性标识'

  `seller_id` varchar(64) NOT NULL COMMENT '卖家Id'

  `state` varchar(64) DEFAULT NULL COMMENT '状态', `fund_transfer_order_no` varchar(256)  

  DEFAULT NULL COMMENT '资金平台返回的状态',  

  PRIMARY KEY (`id`),UNIQUE KEY `uk_scene_identifier`  

  (KEY `idx_seller` (`seller_id`), 

  KEY `idx_seller_transNo` (`seller_id`,`fund_transfer_order_no`(20)) 

  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='资金流水'

该数据库共有三个索引,1个聚簇索引(主键索引),2个非聚簇索(非主键索引)引。

聚簇索引:

PRIMARY KEY (`id`) 

非聚簇索引:

KEY `idx_seller` (`seller_id`),  

KEY `idx_seller_transNo` (`seller_id`,`fund_transfer_order_no`(20)) 

以上两个索引,其实idx_seller_transNo已经覆盖到了idx_seller,由于历史原因,因为该表以seller_id分表,所以是先有的idx_seller,后有的idx_seller_transNo

3、死锁日志

当数据库发生死锁时,可以通过以下命令获取死锁日志:

show engine innodb status 

发生死锁,第一时间查看死锁日志,得到死锁日志内容如下:

Transactions deadlock detected, dumping detailed information. 

2019-03-19T21:44:23.516263+08:00 5877341 [Note] InnoDB:  

 

*** (1) TRANSACTION

TRANSACTION 173268495, ACTIVE 0 sec fetching rows 

mysql tables in use 1, locked 1 

LOCK WAIT 304 lock struct(s), heap size 41168, 6 row lock(s), undo log entries 1 

阅读延展

1
3