为什么日志备份任务已经停止了，log-backup-coordinator还在呢？

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】测试
【 TiDB 版本】v7.0.0
【复现路径】做过哪些操作出现的问题
全量备份完成后，开始运行日志备份任务（为防止日志备份因为gc的原因失败，事先将tidb_gc_run_interval设置为了240h），然后停掉日志备份任务，drop掉除系统库以外的所有数据库，将tidb_gc_run_interval再设置为10m，gc一直未正常运行（tikv的数据目录一直未减小）。
【遇到的问题：问题现象及影响】
查看tidb-server日志发现两条gc相关日志：
1.there’s another service in the cluster requires an earlier safe point. gc will continue with the earlier one.
2.last safe point is later than current one.No need to gc.This might be caused by manually enlarging gc lifetime"] [“leaderTick on”=64a3ba97a100009] [“last safe point”=2024/10/16 01:30:19.000 +08:00] [“current safe point”=2024/10/16 01:30:19.000 +08:00]
因为log-backup-coordinator的safe_point转换以后即为2024-10-16 01:30:19.000000，所以我推测是因为这个log-backup-coordinator导致了gc运行失败。

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面

image
image938×217 8.29 KB

【附件：截图/日志/监控】
tidb-server日志：
image
image956×372 20.3 KB

查看service-gc-safepoint：
image
image956×265 7.61 KB

时间戳转换：
image

2

MySQL [(none)]> select from_unixtime(1729107398);
±--------------------------+
| from_unixtime(1729107398) |
±--------------------------+
| 2024-10-17 03:36:38 |
±--------------------------+
1 row in set (0.00 sec)
bug升级版本或者等到这个时间后自动消除

3

看了下，2024-10-17 03:36:38这个时间，大概就是我结束日志备份的时间，那意思是7.0.0这个版本默认设置的就是24h后消除吗么？bug修复过后就是日志备份结束后会立即消除？这个bug是在哪个版本解决的呢？

4

是这个问题：GC safepoint not moving forward after log backup stopped · Issue #52082 · pingcap/tidb · GitHub
修复 PR：advancer: fix the incorrect gc safepoint behaviours by 3pointer · Pull Request #52835 · pingcap/tidb · GitHub

修复版本在 7.5.2，7.1.5 和 6.5.9。7.0.0 是 DMR 版本，后续的 bugfix 不会带回去；建议使用 LTS 版本。参考：TiDB 版本周期支持策略 | PingCAP 平凯星辰

（不过似乎修复楼主问题的 #52835 还没 Pick 回 Release 版本，前面的修复版本是另一个类似问题的。）

1 个赞
6

学习了， there’s another service in the cluster requires an earlier safe point. gc will continue with the earlier one. 这条日志表明集群中存在另一个服务需要一个更早的safe point，因此GC会使用这个更早的safe point继续进行，如果其他服务（如TiCDC）需要一个更早的safe point，GC将不能删除这些旧数据，以确保这些服务能够正确地读取数据