【巡检问题分析与最佳实践】PolarDB 死锁问题

2021-08-02 640

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云数据库 RDS SQL Server，独享型 2核4GB

云数据库 RDS MySQL Serverless，0.5-2RCU 50GB

云原生数据库 PolarDB MySQL 版，通用型 2核4GB 50GB

简介： 死锁是关系型数据库系统中最为常见的错误，出现在不同事务中同时对某些数据访问加锁时都要等待对方请求中的数据而无法获取锁，数据库系统会自动牺牲回滚代价最小的事务，从而导致对应的写请求失败，更严重的情况是在大量死锁发生时，会导致数据库系统效率低下，堆积进程大量堆积引发性能问题。

+关注继续查看

往期分享

RDS MySQL

RDS PostgreSQL

RDS PostgreSQL 实例IO高问题

RDS PostgreSQL 慢SQL问题

RDS PostgreSQL CPU高问题

RDS SQL Server

RDS SQL Server 磁盘IO吞吐高问题

RDS SQL Server CPU高问题

RDS SQL Server 空间使用问题

PolarDB

PolarDB MySQL CPU高问题

PolarDB 流量 & 代理问题

Redis

Redis 流控问题

Redis 内存高问题

Redis CPU高问题

MongoDB

MongoDB 内存高问题

MongoDB 磁盘IO高问题

MongoDB 空间使用问题

背景

死锁是关系型数据库系统中最为常见的错误，出现在不同事务中同时对某些数据访问加锁时都要等待对方请求中的数据而无法获取锁，数据库系统会自动牺牲回滚代价最小的事务，从而导致对应的写请求失败，更严重的情况是在大量死锁发生时，会导致数据库系统效率低下，堆积进程大量堆积引发性能问题。

一般来说，死锁都是由于逻辑加锁的顺序导致的，也就是我们常说的 ABA死锁，举例：

tran_A 与 tran_B两个请求分别持有对方所需要的第二次update的行锁，就形成了死锁：

此时业务会收到报错信息类似：

Error : Deadlock found when trying to get lock; try restarting transaction

观察数据库内信息：

show engine innodb status\G;
------------------------
LATEST DETECTED DEADLOCK
------------------------
2020-12-01 16:43:28 0x7fe8a0277700
*** (1) TRANSACTION:
TRANSACTION 370942954, ACTIVE 9 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 25713, OS thread handle 140637097146112, query id 237499 106.11.34.226 luhuo_h updating
update sbtest1 set c='tran2_tran1' where id=1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 354 page no 4 n bits 144 index PRIMARY of table `sbtest`.`sbtest1` trx id 370942954 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000161c23e9; asc     # ;;
 2: len 7; hex 23000000151374; asc #     t;;
 3: len 4; hex 80c52f66; asc   /f;;
 4: len 30; hex 7472616e3120202020202020202020202020202020202020202020202020; asc tran1                         ; (total 120 bytes);
 5: len 30; hex 32323139353230373034382d37303131363035323132332d373431343033; asc 22195207048-70116052123-741403; (total 60 bytes);
*** (2) TRANSACTION:
TRANSACTION 370942953, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 25568, OS thread handle 140637096081152, query id 237597 106.11.34.226 luhuo_h updating
update sbtest1 set c='tran1_tran2' where id=2
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 354 page no 4 n bits 144 index PRIMARY of table `sbtest`.`sbtest1` trx id 370942953 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000161c23e9; asc     # ;;
 2: len 7; hex 23000000151374; asc #     t;;
 3: len 4; hex 80c52f66; asc   /f;;
 4: len 30; hex 7472616e3120202020202020202020202020202020202020202020202020; asc tran1                         ; (total 120 bytes);
 5: len 30; hex 32323139353230373034382d37303131363035323132332d373431343033; asc 22195207048-70116052123-741403; (total 60 bytes);
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 354 page no 4 n bits 144 index PRIMARY of table `sbtest`.`sbtest1` trx id 370942953 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 0000161c23ea; asc     # ;;
 2: len 7; hex 24000000191844; asc $     D;;
 3: len 4; hex 8021f170; asc  ! p;;
 4: len 30; hex 7472616e3220202020202020202020202020202020202020202020202020; asc tran2                         ; (total 120 bytes);
 5: len 30; hex 32383733333830323932332d31303534383839343634312d313138363735; asc 28733802923-10548894641-118675; (total 60 bytes);
*** WE ROLL BACK TRANSACTION (2)