本文整理自网络,侵删。
目录
- 概述
- 分布式死锁和单节点死锁的比较单节点死锁
- 分布式死锁
- 分布式死锁的检测与消除
- 收集各节点的锁信息
- 构建等待关系
- 等待关系判环
- 消除死锁
- 总结
概述
分布式数仓应用场景中,我们经常遇到数据库系统 hang 住的问题,所谓 hang 是指虽然数据库系统还在运行,但部分或全部业务无法正常执行。hang 问题的原因有很多,其中以分布式死锁最为常见,本次主要分享在碰到死锁时,如何快速地解决死锁问题。
GaussDB(DWS) 作为分布式数仓,通过锁机制来实行并发控制,因此也存在产生分布式死锁的可能。虽然分布式死锁无法避免,但幸运的是其提供了多种系统视图,能够保证在分布式死锁发生之后,快速地对死锁进行定位。
本文主要介绍了在 GaussDB(DWS) 中,如何通过 SQL 语句,对分布式死锁进行检测和恢复。本文介绍的方法大致分为 4 步:
1. 收集各节点的锁信息。
2. 构建等待关系。
3. 检测循环等待。
4. 中止事务以消除死锁。
本文介绍的方法使用简单,门槛低,可以确保在分布式死锁发生之后,快速解决问题,恢复业务。
分布式死锁和单节点死锁的比较单节点死锁
单节点死锁是指,死锁中的所有锁等待信息来自同一个节点,例如:
-- 事务 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)
构建等待关系
收集到各节点的锁信息之后,就可以开始构建等待关系了。
相关阅读 >>
为php模块添加sql server2012数据库的步骤详解
更多相关阅读请进入《sql》频道 >>

数据库系统概念 第6版
机械工业出版社
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
转载请注明出处:木庄网络博客 » 详解通过SQL进行分布式死锁的检测与消除