仅4步，就可通过SQL进行分布式死锁的检测与消除
摘要：本文主要介绍在 GaussDB(DWS) 中，如何通过 SQL 语句，对分布式死锁进行检测和恢复。
分布式数仓应用场景中，我们经常遇到数据库系统 hang 住的问题，所谓 hang 是指虽然数据库系统还在运行，但部分或全部业务无法正常执行。hang 问题的原因有很多，其中以分布式死锁最为常见，本次主要分享在碰到死锁时，如何快速地解决死锁问题。
GaussDB(DWS) 作为分布式数仓，通过锁机制来实行并发控制，因此也存在产生分布式死锁的可能。虽然分布式死锁无法避免，但幸运的是其提供了多种系统视图，能够保证在分布式死锁发生之后，快速地对死锁进行定位。
本文主要介绍了在 GaussDB(DWS) 中，如何通过 SQL 语句，对分布式死锁进行检测和恢复。本文介绍的方法大致分为 4 步：
1. 收集各节点的锁信息。
2. 构建等待关系。
3. 检测循环等待。
4. 中止事务以消除死锁。
本文介绍的方法使用简单，门槛低，可以确保在分布式死锁发生之后，快速解决问题，恢复业务。
通过 SQL 语句进行分布式死锁的检测与消除
分布式死锁和单节点死锁的比较
单节点死锁
单节点死锁是指，死锁中的所有锁等待信息来自同一个节点，例如：
-- 事务 transaction1
-- 所在节点：CN1 BEGIN; TRUNCATE t1;
EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'; COMMIT; -- 事务 transaction2
-- 所在节点：CN1 BEGIN; TRUNCATE t2;
EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'; COMMIT;
假设上述两个事务的执行顺序如下：
1. [transaction1] TRUNCATE t1
2. [transaction2] TRUNCATE t2
3. [transaction1] EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'
4. [transaction2] EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'
该执行顺序会导致死锁的产生。由于事务 transaction1 和 transaction2 都在 CN1 上执行，死锁中的所有锁等待信息都在 CN1 上，因此该死锁为单节点死锁。
GaussDB(DWS) 支持自动处理单节点死锁。当某个节点上的多个事务陷入循环等待时，数据库系统会自动将其中一个事务中止，从而消除死锁。
分布式死锁
分布式死锁是指，死锁中的锁等待信息来自不同节点。例如：
-- 事务 transaction1
-- 所在节点：CN1 BEGIN; TRUNCATE t1;
EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'; COMMIT; -- 事务 transaction2
-- 所在节点：CN2 BEGIN; TRUNCATE t2;
EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'; COMMIT;
本例与上一节中的例子相比，只有事务 transaction2 的所在节点从 CN1 改为了 CN2。
假设两个事务的执行顺序和上一节中的执行顺序一致，还是会产生死锁，死锁中的锁等待信息如下：
这就是一个典型的分布式死锁，单独看 CN1 或 CN2 上的锁等待信息，都看不出来有死锁，但将多个节点的锁等待信息放到一起看，就能找到有循环等待的现象。
发生分布式死锁时，陷入死锁的事务全部都无法继续执行下去，只有其中一个事务锁等待超时，剩余事务才能继续执行。默认情况下，锁等待超时时间是 20 分钟。
分布式死锁的检测与消除
当我们观察到数据库系统出现 hang 问题时，我们需要通过 SQL 语句检测分布式死锁，如果发现确实存在分布式死锁，还需要对死锁进行消除。接下来以之前的分布式死锁为例，介绍分布式死锁的检测和消除的方法。
收集各节点的锁信息
为了检测分布式死锁，首先需要获得各节点的锁信息。GaussDB(DWS) 中可以通过 PG_LOCKS 视图查询当前节点的锁信息，因此可以通过 EXECUTE DIRECT 语句在所有节点查询 PG_LOCKS 视图，并收集到当前节点中。
注意此处有一个细节，PG_LOCKS 视图中，很多信息是以 OID 类型给出的，例如一个锁加在一个表上，PG_LOCKS 视图会给出表的 OID。由于同一个表在各节点中的 OID 不一定相同，因此不能通过 OID 来标识一个表。在收集锁信息时，需要先将表的 OID 转换成 SCHEMA 名加表名。其它 OID 信息例如分区 OID 等也同理，需要转化为对应的名字。
执行附件中的示例代码 pgxc_locks.sql，就可以收集到各节点的锁信息：
locktype | nodename | datname | usename | nspname | relname | partname | page | tuple | virtualxid | transactionid | virtualtransaction | mode | granted | client_addr | application_name | pid | xact_start | query_start | state | query_id | query
---------------+--------------+----------+---------+---------+---------+----------+------+-------+------------+---------------+--------------------+---------------------+---------+-------------+------------------+-----------------+----------------------------+----------------------------+---------------------+-------------------+-----------------------------------------------------
virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 12/94 | | 12/94 | ExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';
virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 9/298 | | 9/298 | ExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1;
virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 6/161 | | 6/161 | ExclusiveLock | t | | WLMArbiter | 140110762325760 | 2020-12-25 17:20:18.613815 | 2020-12-25 16:53:35.027585 | active | 0 | WLM arbiter sync info by CCN and CNs
virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 5/162 | | 5/162 | ExclusiveLock | t | | WorkloadMonitor | 140110779119360 | 2020-12-25 17:20:27.16458 | 2020-12-25 16:53:35.027217 | active | 0 | WLM monitor update and verify local info
virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 3/325 | | 3/325 | ExclusiveLock | t | | workload | 140110846744320 | 2020-12-25 17:20:25.372654 | 2020-12-25 16:53:35.02741 | active | 72339069014641297 | WLM fetch collect info from data nodes
advisory | cn_5002 | postgres | tyx_1 | | | | | | | | 12/94 | ShareLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';
relation | cn_5002 | postgres | tyx_1 | public | t1 | | | | | | 9/298 | AccessExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1;
relation | cn_5002 | postgres | tyx_1 | public | t1 | | | | | | 12/94 | AccessShareLock | f | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';
transactionid | cn_5002 | postgres | tyx_1 | | | | | | | 10269 | 12/94 | ExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';
transactionid | cn_5002 | postgres | tyx_1 | | | | | | | 10266 | 9/298 | ExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1;
relation | cn_5002 | postgres | tyx_1 | public | t2 | | | | | | 12/94 | AccessExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';
virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 17/433 | | 17/433 | ExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1;
virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 23/692 | | 23/692 | ExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2;
virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 2/1607 | | 2/1607 | ExclusiveLock | t | | workload | 140552945264384 | | 2020-12-25 16:53:35.041283 | active | 0 | WLM fetch collect info from data nodes
transactionid | dn_6001_6002 | postgres | tyx_1 | | | | | | | 10266 | 17/433 | ExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1;
relation | dn_6001_6002 | postgres | tyx_1 | | | | | | | | 23/692 | AccessExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2;
relation | dn_6001_6002 | postgres | tyx_1 | | | | | | | | 17/433 | AccessExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1;
relation | dn_6001_6002 | postgres | tyx_1 | public | t2 | | | | | | 23/692 | ShareLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2;
relation | dn_6001_6002 | postgres | tyx_1 | public | t2 | | | | | | 23/692 | AccessExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2;
省略若干行
(55 rows)
构建等待关系
收集到各节点的锁信息之后，就可以开始构建等待关系了。
事务 A 等待事务 B，需要满足 3 个条件：
1. 两个事务加锁的资源相同（同一个表、同一个分区、同一个页面或同一个元组等）。特别注意，如果事务 A 对 DN1 的 t1 表的加锁，事务 B 对 DN2 的 t1 表的加锁，则我们认为它们加锁的资源不同，只有同一节点上的同一资源才被认为是相同的资源。
2. 事务 B 已经持有锁，而事务 A 还未持有锁。
3. 事务 A 和事务 B 申请的锁的级别互斥。
通过对上一步收集到的锁信息进行处理，就可以构建出事务的等待关系。
执行附件中的示例代码 pgxc_locks_wait.sql，就可以获得等待关系：
locktype | nodename | datname | acquire_lock_pid | hold_lock_pid | acquire_lock_event | hold_lock_event
----------+----------+----------+------------------+-----------------+-------------------------------------------------------------------------+--------------------------------------------------------
relation | cn_5001 | postgres | 140508814374656 | 140508792350464 | usename : tyx_1 +| usename : tyx_1 +
| | | | | nspname : public +| nspname : public +
| | | | | relname : t2 +| relname : t2 +
| | | | | partname : +| partname : +
| | | | | page : +| page : +
| | | | | tuple : +| tuple : +
| | | | | virtualxid : +| virtualxid : +
| | | | | transactionid : +| transactionid : +
| | | | | virtualtransaction: 11/13 +| virtualtransaction: 12/1323 +
| | | | | mode : AccessShareLock +| mode : AccessExclusiveLock +
| | | | | client_addr : +| client_addr : ::1/128 +
| | | | | application_name : gsql +| application_name : cn_5002 +
| | | | | xact_start : 2020-12-25 17:18:40.478704 +| xact_start : 2020-12-25 17:18:54.238933 +
| | | | | query_start : 2020-12-25 17:19:23.0923 +| query_start : 2020-12-25 17:18:54.239319 +
| | | | | state : active +| state : idle in transaction +
| | | | | query_id : 0 +| query_id : 0 +
| | | | | query : EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t2';+| query : TRUNCATE t2; +
| | | | | ------------------------------------------------------ | ------------------------------------------------------
relation | cn_5002 | postgres | 140110481323776 | 140110672164608 | usename : tyx_1 +| usename : tyx_1 +
| | | | | nspname : public +| nspname : public +
| | | | | relname : t1 +| relname : t1 +
| | | | | partname : +| partname : +
| | | | | page : +| page : +
| | | | | tuple : +| tuple : +
| | | | | virtualxid : +| virtualxid : +
| | | | | transactionid : +| transactionid : +
| | | | | virtualtransaction: 12/94 +| virtualtransaction: 9/298 +
| | | | | mode : AccessShareLock +| mode : AccessExclusiveLock +
| | | | | client_addr : +| client_addr : ::1/128 +
| | | | | application_name : gsql +| application_name : cn_5001 +
| | | | | xact_start : 2020-12-25 17:18:54.238933 +| xact_start : 2020-12-25 17:18:40.478704 +
| | | | | query_start : 2020-12-25 17:19:37.715447 +| query_start : 2020-12-25 17:18:40.479682 +
| | | | | state : active +| state : idle in transaction +
| | | | | query_id : 0 +| query_id : 0 +
| | | | | query : EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';+| query : TRUNCATE t1; +
| | | | | ------------------------------------------------------ | ------------------------------------------------------
(2 rows)
等待关系判环
构建出事务的等待关系之后，就可以通过检查等待关系是否成环，来判断当前是否有分布式死锁。
一般情况下，等待关系不会太多，通过观察就可以判断出当前有无分布式死锁。通过观察上一节中构建的等待信息，可以很容易地判断出事务 transaction1 和 transaction2 发生了循环等待，即产生了死锁。
消除死锁
上一步最终可能会找到等待关系中的一个或多个环，对于每个环，需要中止环中的一个事务，才能消除死锁。至于应该选择环中的哪个事务进行中止，需要我们从事务的重要性、已执行时间等多方面进行考虑，最终选择一个对业务影响最小的事务进行中止。
总结
通过 SQL 语句，我们可以很方便地处理分布式死锁。当我们在实际业务中遇到数据库系统 hang 住的问题时，可以借助本文提供的方法，检查 hang 问题是否是分布式死锁引起的，如果问题确实是由分布式死锁引起的，还可以通过中止某个陷入死锁的事务，来快速恢复业务。
附件下载： lock.zip 2.29KB
本文分享自华为云社区《如何通过SQL进行分布式死锁的检测与消除》，原文作者：tyxxjtu。
仅4步，就可通过SQL进行分布式死锁的检测与消除的更多相关文章
- （转载）一步一步学Linq to sql系列文章
现在Linq to sql的资料还不是很多,本人水平有限,如果有错或者误导请指出,谢谢. 一步一步学Linq to sql(一):预备知识 一步一步学Linq to sql(二):DataContex ...
- 一步一步学Linq to sql（五）：存储过程
普通存储过程 首先在查询分析器运行下面的代码来创建一个存储过程: create proc sp_singleresultset as set nocount on select * from cust ...
- SQL SERVER 分布式事务(DTC)
BEGIN DISTRIBUTED TRANSACTION指定一个由 Microsoft 分布式事务处理协调器 (MS DTC) 管理的 Transact-SQL 分布式事务的起始. 语法BEGIN ...
- sqlserver 抓取所有执行语句 SQL语句分析 死锁 抓取
原文:sqlserver 抓取所有执行语句 SQL语句分析 死锁 抓取 在多人开发中最头疼的是人少事多没有时间进行codereview,本来功能都没时间写,哪有时间来开会细细来分析代码.软件能跑就行, ...
- 解决SQL server2005数据库死锁的经验心得
前段时间提到的"sql server 2005 死锁解决探索",死锁严重,平均每天会发生一次死锁,在解决和处理SQL server2005死锁中查了很多资料和想了很多办法,后来我们 ...
- 监控SQL Server正在执行的SQL语句和死锁情况
原文:监控SQL Server正在执行的SQL语句和死锁情况 SELECT [Individual Query] = SUBSTRING(qt.TEXT, er.statement_start_off ...
- 面试官：请用SQL模拟一个死锁
文章首发于公众号:BiggerBoy 有读者说面试被问到怎么用SQL模拟数据库死锁? 这位读者表示对Java中的死锁还是略知一二的,但是突然用SQL写死锁的案例之前还真没遇到过,这个问题没答上来.所以 ...
- DBArtist之Oracle入门第3步: 安装配置PL/SQL Developer
操作系统: WINDOWS 7 (64位) 数据库: Oracle 11gR2 (64位) PL/SQL Developer : PL/SQL ...
- Android仅2步实现 滚粗 汉堡导航栏效果~ 全新底部导航交互(滑动隐藏)
本文同步自wing的地方酒馆 布吉岛大家有木有看这一篇文章,再见,汉堡菜单,我们有了新的 Android 交互设计方案 本库下载地址:https://github.com/githubwing/Bye ...
随机推荐
- Spring Boot 实现看门狗功能 (调用 Shell 脚本)
需要实现看门狗功能,定时检测另外一个程序是否在运行,使用 crontab 仅可以实现检测程序是否正在运行,无法做到扩展,如:手动重启.程序升级(如果只需要实现自动升级功能可以使用 inotify)等功 ...
- OpenCV-Python图像转换为PyQt图像的变形及花屏无法正常显示问题研究
☞ ░ 前往老猿Python博文目录 ░ 一.引言 在<PyQt转换显示Python-OpenCV图像实现图形化界面的视频播放>介绍了实现在OpenCV和PyQt之间转换并传递图像实现在P ...
- 什么是Python生成器？与迭代器的关系是什么？
生成器是一个特殊的迭代器,它保存的是算法,每次调用next()或send()就计算出下一个元素的值,直到计算出最后一个元素,没有更多的元素时,抛出StopIteration.生成器有两种类型,一种是生 ...
- windows下使用pyinstaller将多个目录的Python文件打包成exe可执行文件
专栏:Python基础教程目录 专栏:使用PyQt开发图形界面Python应用 专栏:PyQt入门学习 老猿Python博文目录 一.引言 需要将一个工程涉及两个目录的模块文件打包成exe,打包环境如 ...
- PyQt开发案例：结合QDial实现的QStackedWidget堆叠窗口程序例子及完整代码
老猿Python博文目录 专栏:使用PyQt开发图形界面Python应用 老猿Python博客地址 一.案例说明 本案例是老猿在学习QStackedWidget中的一个测试案例,该案例使用QStack ...
- 彻底搞懂js __proto__ prototype constructor
在开始之前,必须要知道的是:对象具有__proto__.constructor(函数也是对象固也具有以上)属性,而函数独有prototype 在博客园看到一张图分析到位很彻底,这里共享: 刚开始看这图 ...
- css改变svg的颜色
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...
- Pytorch训练时显存分配过程探究
对于显存不充足的炼丹研究者来说,弄清楚Pytorch显存的分配机制是很有必要的.下面直接通过实验来推出Pytorch显存的分配过程. 实验实验代码如下: import torch from torch ...
- 写给OIer们的一些话（修订版）
我是一个高二的OIer,离我正式退役的日子已经不超过一年了.在这个时期,与其写一些回忆性的文字,不如跳出"自我"的范畴,以一种比较全局的角度和大家一起分享一些我对OI的认知和看法. ...
- 蒲公英 · JELLY技术周刊 Vol.34: 芜湖～ Flutter
蒲公英 · JELLY技术周刊 Vol.34 提及跨端,你能想到那些技术?PWA.小程序.Ionic.React Native.Weex--当然也少不了 Flutter,历时 3 年,Flutter ...