OceanBase 数据库 V3.x 版本突然出现大量的无主选举

问题现象

突然出现大量的无主选举。查看无主选举的原因是 clog sliding window timeout，这个通常是 clog 超过 10 秒没有达成多数派并滑出。

当时还发现有 500 租户的队列积压，在 OceanBase 数据库 V3.x 版本中 500 租户就负责 clog，所以主要需要排查 500 租户队列积压的原因。

关键信息

1. 500 租户队列积压： 在日志中搜索 dump tenant info。

2. 大事务： 搜索 callback 关键字，查看 count 的大小，查看是否超过了千万级别。

   

3. 冻结： 可以通过 timer task cost too much time 看有没有冻结或者合并的 task 任务。

   

问题原因

前置知识：

• 在 OceanBase 数据库 V3.x 版本如果事务的回调函数比较多就会导致时间比较久，会持有回放引擎的读锁。

• 合并和冻结是要持有回放引擎的写锁。

• 回放引擎为了保证想要持有写锁线程不会被饿死，做了写锁优先原则。

• 500 租户负责 clog 同步，需要持有回放引擎的读锁才能完成 clog 同步。

500 租户的队列积压通常都是因为获取不到锁导致的队列积压。 当查看当时有大事务（里面的回调函数达到了千万级别），会处理的会比较慢，该事务过程中会给回放引擎上读锁。如果这个时候出现合并或者冻结，需要给回放引擎上写锁。大事务会阻塞合并和冻结，clog 想要同步需要给回放引擎上读锁但是由于写锁优先的策略就需要等合并执行完成。这个过程就导致读锁 -> 写锁 -> 读锁这个过程，读锁需要等写锁上完。如果 clog 的读锁迟迟上不上去会导致无主的产生。

总结：

因为大事物和冻结的存在导致 500 租户无法获取到回放引擎的读锁，所以 500 租户队列积压，500 租户 clog 处理无法在 10秒内达成多数派并滑出，造成分区的卸任从而造成无主。

问题的风险及影响

无主选举的产生。

适用版本

OceanBase 数据库 V3.x 版本。

解决方法

• 减少大事务，将大事务拆分成多个事务来执行。

• 不要在合并或者冻结期间执行大事务。

• 升级 OceanBase 数据库版本至 V4.x 版本。

规避方式

• 减少大事务，将大事务拆分成多个事务来执行。

• 不要在合并或者冻结期间执行大事务。