GaussDB(DWS)中的分布式死锁问题实践

3）CU更新冲突

# 集群两个CN，两个DN
create table mytable(a int, b int) with (orientation = column);
insert into mytable values(1,1),(2,2),(3,3),(4,4);

      其中sessionA与sessionB可由相同或者不同CN发起，执行时序如下：

    当出现更新冲突时，对于行存表来说是对一行数据加锁（如场景2所述），但对于列存表来说是对一个CU加锁。所以一个事务里的更新语句如果涉及到不同的CU，也会拿事务锁，可能就会产生分布式死锁。

    我们可以通过如下语句观察ctid信息判断数据是否分布在同一个CU上，如下图：可以看到a = 1 与 a = 3分布在DN1上，且在同一个CU；a = 2 与 a = 4分布在DN2上，且在同一个CU。所以这也能解释为什么看上去列存表更新不同的“行数据”也会产生锁阻塞和分布式死锁现象。

4）单语句出现分布式死锁

     前面几种场景都是事务块里涉及到多条SQL语句，可能会到不同节点上去交错拿锁导致的分布式死锁，但有时候某些单语句场景可能也会出现分布式死锁，如下：

      此类问题与数据分布有关，如下场景都可能会导致这个现象：

     1）若表是复制表，每个DN节点上都有数据，更新时会去所有DN并发执行

     2）表是普通行存表或列存表，但有行数据（如a=1）同时分布在了多个DN节点上，如round robin分布下插入两条相同a=1的数据

insert into mytable values(1,1)；
insert into mytable values(1,2)；

         此场景需要具体去排查数据分布是否会造成此情况。

1）控制锁级别，减少锁升级

     按照各类操作的锁级别建议规则使用，开发时不要盲目提高锁级别，造成可能发生的不必要的锁等待

2）控制锁粒度

    合理控制锁使用范围，及时释放

3）控制拿锁顺序

     尽量控制对资源操作的顺序，比如对各分区表的操作顺序，避免乱序造成的死锁。但全局各节点的拿锁情况或顺序一般无法提前预测，往往为了考虑提高性能，请求会在节点间并发执行，但我们可以在某个节点上控制并发互斥以规避分布式死锁问题，如操作某个表时先去FirstCN上请求持锁，持锁成功后再对其他CN和DN并行拿锁。GaussDB(DWS)内核的很多地方的设计中会有这种思想，如DDL语句，autoanalyze等。

4）主动设置较短的锁超时时间

     一般用在非关键的用户路径操作上，如用户语句在runtime analyze子事务的流程里会主动设置锁超时时间为2秒，发生阻塞后可及时放锁，避免出现长时间锁等待，也能规避潜在的分布式死锁场景

4、如何排查系统是否产生了分布式死锁

      本质上是发现集群中是否有全局的死锁环等待关系，内核中提供有许多视图可以辅助观察持锁等待情况，但需要注意的是，因为查询到的锁等待关系可能只是暂时的瞬间状态，只有持续存在的锁等待才会造成分布式死锁，需要判断锁是否稍后会主动释放（事务提交前），还是只能等到事务提交后释放。如何判断系统是否产生了分布式死锁，有以下方法：

1）查询pgxc_deadlock视图，会输出全局死锁环信息，如果信息为空，则代表无分布式死锁，但需要注意在某些复杂的场景可能会出现误报，即输出有死锁环信息，但可能并没有形成分布式死锁；

    当有分布式死锁时，直到等待锁超时后，某一方事务会出现“Lock wait timeout...”，打印具体的锁信息及锁语句，报错后释放锁，另一方解除阻塞。相关的锁超时参数是lockwait_timeout或update_lockwait_timeout。

2）在GaussDB(DWS)的8.3.0版本及以后，内核已经支持了自动化地分布式死锁检测，当检测到系统中存在分布式死锁等待关系后，会自动报错和挑选事务进行cancel，具体原理下一节中会详细介绍。

     如下图所示，若用户出现“cancelled by global deadlock detector”报错，代表检测到分布式死锁并被查杀，此时可以去检测CN上（FirstCN或者CCN）上去找相关日志信息，会输出具体死锁和session查杀信息，需要注意用户语句执行CN和检测CN可能并不是一个，此时检测CN会向执行CN发起事务cancel。

5、分布式死锁检测原理

      分布式死锁检测的目标原则是做到不误报，争取不漏报，尽量及时报。

      我们使用了中心化的收集检测思想，如流程图所示：首先挑选一个CN作为检测CN（类似master角色），CN上新增后台线程启动GlobalDeadlockDetector模块，周期性向集群所有节点收集锁等待关系，计算等待者和持有者信息，然后构造全局有向图（WFG），依赖定义的规则对图的顶点和边进行消除，判断是否能消除完成。如果无法消除完成，则出现了死锁环，并进行二次DoubleCheck，如果两次的死锁环信息有交集，则报告死锁信息。当发现死锁后，按照事务时间戳挑选最年轻的事务（youngest）进行中断，并会对用户报错。

     我们在设计上主要参考了Greenplum的思路，由于与GaussDB(DWS)架构和应用场景上的差异性，也针对做了一些改造和优化，主要包括：

• 检测节点的选择：在FirstCN或CCN上启动后台检测线程，依赖外部OM模块做高可用切换；

• 等待关系图节点的标识：由检测CN构造全局唯一global_session下发，格式为：timestamp.pid.node_name（timestamp为事务开始的时间戳，pid为执行CN上的线程号，node_name为执行CN名称）；

• 虚实边关系定义：支持定义线程级别虚实边，过滤掉不必要的死锁误报；

• 死锁结果的合法性检查：增加DoubleCheck机制，提高检测结果准确性，结果以连续两次检测到的死锁环交集为准；

• 死锁消除：执行CN与检测CN可能不同，可能存在跨CN发起的事务中断；

• 与单机死锁检测算法互补：当分布式死锁检测算法如果发现检测到单机的死锁环路等待关系后，则忽略，与单机死锁检测算法处理不冲突；             

  分布式死锁检测相关参数：

  • enable_global_deadlock_detector：分布式死锁检测功能是否开启，默认off

  • global_deadlock_detector_period：分布式死锁检测周期，默认5秒