概述

分布式数仓应用场景中，我们经常遇到数据库系统 hang 住的问题，所谓 hang 是指虽然数据库系统还在运行，但部分或全部业务无法正常执行。hang 问题的原因有很多，其中以分布式死锁最为常见，本次主要分享在碰到死锁时，如何快速地解决死锁问题。

gaussdb(dws) 作为分布式数仓，通过锁机制来实行并发控制，因此也存在产生分布式死锁的可能。虽然分布式死锁无法避免，但幸运的是其提供了多种系统视图，能够保证在分布式死锁发生之后，快速地对死锁进行定位。

本文主要介绍了在 gaussdb(dws) 中，如何通过 sql 语句，对分布式死锁进行检测和恢复。本文介绍的方法大致分为 4 步：

1. 收集各节点的锁信息。

2. 构建等待关系。

3. 检测循环等待。

4. 中止事务以消除死锁。

本文介绍的方法使用简单，门槛低，可以确保在分布式死锁发生之后，快速解决问题，恢复业务。

分布式死锁和单节点死锁的比较单节点死锁

单节点死锁是指，死锁中的所有锁等待信息来自同一个节点，例如：

假设上述两个事务的执行顺序如下：

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) 支持自动处理单节点死锁。当某个节点上的多个事务陷入循环等待时，数据库系统会自动将其中一个事务中止，从而消除死锁。

分布式死锁

分布式死锁是指，死锁中的锁等待信息来自不同节点。例如：

本例与上一节中的例子相比，只有事务 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，就可以收集到各节点的锁信息：

构建等待关系

收集到各节点的锁信息之后，就可以开始构建等待关系了。

事务 a 等待事务 b，需要满足 3 个条件：

1. 两个事务加锁的资源相同（同一个表、同一个分区、同一个页面或同一个元组等）。特别注意，如果事务 a 对 dn1 的 t1 表的加锁，事务 b 对 dn2 的 t1 表的加锁，则我们认为它们加锁的资源不同，只有同一节点上的同一资源才被认为是相同的资源。

2. 事务 b 已经持有锁，而事务 a 还未持有锁。

3. 事务 a 和事务 b 申请的锁的级别互斥。

通过对上一步收集到的锁信息进行处理，就可以构建出事务的等待关系。

执行附件中的示例代码 pgxc_locks_wait.sql，就可以获得等待关系：

等待关系判环

构建出事务的等待关系之后，就可以通过检查等待关系是否成环，来判断当前是否有分布式死锁。

一般情况下，等待关系不会太多，通过观察就可以判断出当前有无分布式死锁。通过观察上一节中构建的等待信息，可以很容易地判断出事务 transaction1 和 transaction2 发生了循环等待，即产生了死锁。

消除死锁

上一步最终可能会找到等待关系中的一个或多个环，对于每个环，需要中止环中的一个事务，才能消除死锁。至于应该选择环中的哪个事务进行中止，需要我们从事务的重要性、已执行时间等多方面进行考虑，最终选择一个对业务影响最小的事务进行中止。

总结

通过 sql 语句，我们可以很方便地处理分布式死锁。当我们在实际业务中遇到数据库系统 hang 住的问题时，可以借助本文提供的方法，检查 hang 问题是否是分布式死锁引起的，如果问题确实是由分布式死锁引起的，还可以通过中止某个陷入死锁的事务，来快速恢复业务。

以上就是详解通过sql进行分布式死锁的检测与消除的详细内容，更多关于通过sql进行分布式死锁的检测与消除的资料请关注其它相关文章！

原文链接：https://www.cnblogs.com/huaweiyun/p/14214901.html