摘要 ：本文次要介绍在 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;
假如上述两个事务的执行程序如下：
- [transaction1] TRUNCATE t1
- [transaction2] TRUNCATE t2
- [transaction1] EXECUTE DIRECT ON(DN1) ‘SELECT * FROM t2’
- [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 个条件：
- 两个事务加锁的资源雷同（同一个表、同一个分区、同一个页面或同一个元组等）。特地留神，如果事务 A 对 DN1 的 t1 表的加锁，事务 B 对 DN2 的 t1 表的加锁，则咱们认为它们加锁的资源不同，只有同一节点上的同一资源才被认为是雷同的资源。
- 事务 B 曾经持有锁，而事务 A 还未持有锁。
- 事务 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。
点击关注，第一工夫理解华为云陈腐技术~