tidb使用ticdc进行同步到下游tidb集群，为了保持数据一致性，使用了redo log，但是redo log一直增长不删除

[松隐青峦]

在 v7.5.5 版本中，检查 GC Safepoint 的步骤如下：

1. 查询当前 GC Safepoint 时间戳
   在上游 TiDB 执行 SQL：

   SELECT VARIABLE_VALUE AS gc_safe_point
   FROM mysql.tidb
   WHERE VARIABLE_NAME = 'tikv_gc_safe_point';
   

   输出示例：

   +----------------------------+
   | gc_safe_point              |
   +----------------------------+
   | 2024-06-01 12:00:00.000000 |
   +----------------------------+
   

2. 关联 TiCDC 同步进度
   查看 TiCDC Changefeed 的 checkpoint-ts：

   ./cdc cli changefeed list --pd=http://pd:2379
   

   输出示例：

   {
     "id": "ticdc-zhongtai-bak",
     "checkpoint-ts": 456128358773424215,
     "checkpoint-time": "2024-06-01 12:30:00.000"
   }
   

   • 关键逻辑：若 checkpoint-ts 大于 gc_safe_point 的时间戳，说明 TiCDC 同步进度正常，GC Safepoint 应能推进，Redo Log 应被清理。
   • 异常情况：如果 gc_safe_point 长时间停滞，需检查 TiCDC 服务状态或下游同步是否阻塞。

为何 v7.5.5 可能因 GC Safepoint 导致 Redo Log 堆积？
以下是常见原因和修复方案：

原因	现象	解决方案
TiCDC 服务异常或宕机	GC Safepoint 停止更新	重启 TiCDC 节点，确保集群健康
下游同步长时间阻塞	checkpoint-ts 不推进	解决下游写入问题（如死锁、高负载）
TiCDC 与 PD 网络隔离	TiCDC 无法注册 Service GC Safepoint	检查网络连通性，确保 TiCDC 可访问 PD 节点
上游 TiDB 的 GC 生命周期过短	GC 过早清理未同步的数据	调整 GC 生命周期： SET GLOBAL tidb_gc_life_time = '24h';（默认 10m）

---

4. 针对 v7.5.5 的 Redo Log 清理优化建议

若无法立即升级版本，可通过以下配置和操作缓解问题：

1. 调整 GC 生命周期
   延长上游 GC 时间，避免数据被过早清理：

   -- 在上游 TiDB 执行
   SET GLOBAL tidb_gc_life_time = '24h';  -- 根据业务需求调整
   

2. 优化 TiCDC 配置
   修改 Changefeed 配置，减少 Redo Log 碎片：

   [consistent]
   level = "eventual"
   max-log-size = 128     # 增大单个文件大小（单位 MiB）
   flush-interval = 1000  # 降低刷新间隔（单位毫秒）
   storage = "local:///disk1/zhongtai_bak_redo"
   

3. 监控 GC Safepoint 推进
   在 Grafana 监控面板中观察以下指标：

   • TiCDC > Service GC Safepoint：确认 Safepoint 时间戳持续更新。
   • TiKV-Details > GC > GC Safepoint：确保与 TiCDC 的 Safepoint 一致。

哥们，也不知道对不对。你看着查吧。

[l940399478]

1.查询当前GC Safepoint时间戳
mysql> SELECT VARIABLE_VALUE AS gc_safe_point
→ FROM mysql.tidb
→ WHERE VARIABLE_NAME = ‘tikv_gc_safe_point’;
±----------------------------+
| gc_safe_point |
±----------------------------+
| 20250304-15:06:07.629 +0800 |
±----------------------------+
1 row in set (0.00 sec)
2.关联TiCDC同步进度
{
“id”: “ticdc-zhongtai-bak”,
“namespace”: “default”,
“summary”: {
“state”: “normal”,
“tso”: 456456909299122191,
“checkpoint”: “2025-03-06 15:08:43.779”,
“error”: null
}
}

[hicqu-PingCAP (qupeng)]

我测试了 v7.5.5 的 redo 功能，是可以正确清理掉过期文件的。您那里手动清理后，麻烦再观察下是否无法清理的现象仍然存在呢？

[l940399478]

我清理看下，能帮看下，我这个cdc任务创建、配置文件都写的有问题吗

[l940399478]

发现一个现象，3个cdc节点，有一个节点存放redo的目录下的xxxx:8300_default_ticdc-zhongtai-bak_meta_671443d1-948d-4da1-9219-e9a1c31d6ad7.meta 文件是不断变化的，这个节点的redo也是仅有最近的几个.log文件。另外两个节点的xxxx:8300_default_ticdc-zhongtai-bak_meta_f5364027-0904-4853-bebe-ebff9c30268f.meta文件是不变的，这些节点的.log文件也是一直没清理

[l940399478]

也就是只有cdc为owner的节点下的redo是正常清理的，另外两个非owner节点的cdc下的redo是没清理的

[hicqu-PingCAP (qupeng)]

哦，我明白了，这是预期的行为。

cdc 只有 changefeed 的 owner 会清理这个 changefeed 的 redo 日志。设计上，所有 cdc 节点的 redo 目录都应该指向同一个 NFS 挂载点，这样 owner 就能够把 processor 生成的 redo 文件清理掉。

您的用法中，似乎 3 个 cdc 实例的 redo 目录并没有指向同一个 NFS 挂载点。

[l940399478]

是的，应该就是这样了