TiCDC监控 gc time 不推进了（正常10分钟会gc一次）

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境 /测试环境
TiCDC监控曲线gc time突然不推进了（正常10分钟会gc一次）。所有任务都是正常状态，ticdc也没有报错日志。期间也没有修改过 tidb_gc_life_time

mysql> show variables like ‘tidb_gc_life_time’;
±------------------±------+
| Variable_name | Value |
±------------------±------+
| tidb_gc_life_time | 10m0s |
±------------------±------+
1 row in set (0.01 sec)

mysql> SELECT * FROM mysql.tidb WHERE variable_name = ‘tikv_gc_safe_point’;
±-------------------±----------------------------±-------------------------------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE | COMMENT |
±-------------------±----------------------------±-------------------------------------------------------------+
| tikv_gc_safe_point | 20260114-13:35:51.718 +0800 | All versions after safe point can be accessed. (DO NOT EDIT) |
±-------------------±----------------------------±-------------------------------------------------------------+
1 row in set (0.01 sec)

流式获取执行结果会导致 tikv_gc_safe_point 无法推进吗？

1 个赞
2

TiDB 的 GC safe point 推进的前提是：所有 TiDB/TiCDC/TiFlash 等组件都确认已完成对该时间点前数据的访问。如果存在以下情况，GC safe point 会被 “卡住”：

  1. 存在未结束的长事务（包括显式事务、隐式事务）；
  2. TiCDC 的同步任务持有旧的时间戳（例如消费位点长时间未推进，或任务处于 “已暂停但未清理” 状态）；
  3. 流式查询 / 长连接持有快照读的时间戳（即使用START TRANSACTION WITH CONSISTENT SNAPSHOT或SET tidb_snapshot的长时间未关闭连接）。
临时解决

sql

-- 1. 清理异常的TiCDC任务（确认无业务影响后）
DROP CHANGEFEED IF EXISTS `changefeed_name`;

-- 2. 终止长事务/闲置连接（替换CONNECTION_ID）
KILL [CONNECTION | QUERY] CONNECTION_ID;

-- 3. 手动触发GC（仅测试环境，生产需谨慎）
ADMIN CLEANUP DELETES 1000;
  • 业务层面：
  • 避免流式查询长时间持有快照，及时关闭连接；
  • 拆分长事务，控制单事务执行时间（建议不超过 10 分钟）；
  • 监控层面：
  • 新增tikv_gc_safe_point推进延迟告警（超过 15 分钟即告警）；
  • 监控 TiCDC 的checkpoint lag指标，及时发现消费延迟。
2 个赞
3

看下有么有长事务

4

已确认是 StreamingResult 流式获取执行结果 导致的。流式任务停止之后就会继续推进了

https://docs.pingcap.com/zh/tidbcloud/dev-guide-timeouts-in-tidb/#gc-超时

5

监控gc时需要注意磁盘空间85%阈值设置。 欢迎继续交流讨论。

6

augenstern的回答看上去是最合理的

7

流式获取执行结果（如持续未结束的流式查询、长事务）会持有旧版本数据的读取快照，而 TiKV 的 GC 安全点需等待所有活跃读取 / 事务任务完成后才能推进，此类长期未结束的任务会阻塞 GC 安全点更新。

8

清理下异常的任务

9

长事务影响了，检查processlist就好。