Tikv GC Worker 死锁问题分析与解决方案

背景介绍

在分布式数据库Tikv中，垃圾回收(GC)是一个重要的后台维护任务，负责清理不再需要的历史数据版本。GC Worker是执行这一任务的核心组件，它通过定期扫描和清理过期数据来释放存储空间。

问题现象

在特定场景下，当禁用compaction-filter功能时，Tikv会采用传统的GC方式逐个处理各个region。此时系统可能出现GC任务完全阻塞的情况，特别是在遇到"channel is full"等错误时。

技术分析

死锁产生机制

问题的核心在于GC任务调度过程中存在的潜在死锁风险。具体表现为：

1. GC Manager在调用async_gc_next_region时会持有current_tasks锁
2. 在回调函数(callback)中也需要获取同一个锁
3. 当遇到错误(如channel已满)时，会直接执行回调函数
4. 由于锁未被释放，导致死锁情况发生

默认配置下的行为

在默认配置中：

• GC Worker线程数默认为1
• GC任务队列大小默认为4096
• 并发任务数(current_tasks)受到严格限制

理论上，在默认配置下这个问题不容易触发，因为：

1. maybe_wait()会确保current_tasks不超过max_concurrent_tasks-1
2. 只有当上一个任务完成后才会调度新任务
3. current_tasks计数器在任务成功调度时增加，在回调时减少

解决方案

要解决这个问题，需要调整锁的获取和释放时机：

1. 在调用async_gc_next_region前释放current_tasks锁
2. 确保回调函数执行时能够正常获取所需锁
3. 对错误处理路径进行优化，避免在持有锁的情况下执行回调

影响范围

该问题影响多个Tikv版本，包括但不限于6.5、7.1、7.5、8.1和8.5等版本。特别是在以下场景更容易出现：

• 使用传统GC方式(禁用compaction-filter)
• GC任务队列压力较大时
• 处理特殊GC任务类型(如UnsafeDestroyRange)时

最佳实践

对于使用受影响版本的用户，建议：

1. 监控GC Worker的运行状态
2. 关注GC任务队列的使用情况
3. 在必要时调整GC相关参数
4. 及时升级到包含修复的版本

通过理解这一问题的本质和解决方案，可以帮助运维人员更好地管理Tikv集群的GC行为，确保系统的稳定运行。