TiKV中GC Worker使用ConcurrencyManager导致错误日志问题分析

问题背景

在TiKV分布式键值存储系统中，垃圾回收(GC)是一个重要的后台维护机制。近期在TiKV v8.5.1版本中发现了一个与GC Worker相关的问题，当禁用compaction filter功能时，系统会持续输出大量错误日志，影响系统运行体验。

问题现象

当用户将配置项enable-compaction-filter设置为false时，TiKV会频繁打印以下错误日志：

[ERROR] ["improper setting: limit_valid_duration >= max_ts_drift_allowance; consider increasing max-ts-drift-allowance or decreasing max-ts-sync-interval"] [max_ts_drift_allowance=0ns] [limit_valid_duration=45s]

通过分析堆栈信息可以发现，这个问题源于GC Worker在创建事务时使用了ConcurrencyManager::new方法，而没有使用更合适的ConcurrencyManager::new_with_config方法。

技术分析

ConcurrencyManager的作用

ConcurrencyManager是TiKV中负责管理事务并发控制的组件，它维护了事务的时间戳信息和锁信息，确保事务的隔离性和一致性。在创建ConcurrencyManager实例时，需要正确配置时间戳相关的参数。

问题根源

GC Worker在创建事务时直接调用了ConcurrencyManager::new方法，这个方法内部会使用默认配置创建实例。而实际上，GC Worker应该使用ConcurrencyManager::new_with_config方法，传入适当的配置参数。

具体来说，错误日志中提到的两个关键参数：

• max_ts_drift_allowance：允许的最大时间戳漂移量
• limit_valid_duration：限制有效持续时间

当limit_valid_duration大于等于max_ts_drift_allowance时，系统会认为配置不合理，从而产生错误日志。

影响范围

这个问题主要影响以下场景：

1. 运行TiKV v8.5.1版本
2. 配置中禁用了compaction filter功能
3. GC Worker执行垃圾回收操作时

虽然这个问题不会导致数据不一致或系统崩溃，但持续的错误日志输出会影响系统监控和日志分析。

解决方案

该问题已在后续版本中修复，主要修改包括：

1. GC Worker改为使用ConcurrencyManager::new_with_config方法
2. 确保传入合理的配置参数
3. 避免不必要的时间戳校验

对于使用TiKV v8.5.1版本的用户，建议升级到已修复该问题的版本。如果暂时无法升级，可以考虑以下临时解决方案：

1. 保持compaction filter功能启用
2. 调整日志级别过滤相关错误日志
3. 根据实际情况调整时间戳相关参数

最佳实践

对于TiKV的配置和使用，建议：

1. 定期检查系统日志，及时发现类似问题
2. 升级前仔细阅读版本变更说明
3. 对于关键配置项的修改，先在测试环境验证
4. 关注GC相关指标，确保垃圾回收机制正常运行

通过这个案例，我们可以看到TiKV作为一个复杂的分布式系统，各个组件之间的交互需要精心设计，配置参数的传递和使用也需要格外注意，以避免类似问题的发生。