【 TiDB 使用环境`】生产环境
【 TiDB 版本】5.1.0
【问题现象及影响】
早期集群曾经使用ticdc组件同步数据到kafka，后来cdc废弃之后没有缩容。
近期偶然发现集群的数据量有些不正常，备份出来只有十几GB但是磁盘占用高达3TB。
于是查找了一下原因，发现是gc进程无法推进gc safepoint，看了下cdc changefeed list的这个同步停止的checkpoint与gc safepoint停止的时间一致。
尝试直接remove changefeed发现显示删除成功实际隔几秒重现回来，现在把cdc组件直接缩容后重启了gc leader的tidb节点，发现gc leader切换后gc依旧无法推进，看日志像是gc依旧被阻塞。
现计划直接重启整个tidb组件，如无效则计划重启整个集群。
但是业务对集群可用性要求较高，因此想先请教下如果只重启tidb组件或pd组件是否可以处理此问题。
可以看看这个https://tidb.net/blog/36c58d32。具体看看gc leader 的报错日志 是不是也是这样的["[gc worker] there’s another service in the cluster requires an earlier safe point. gc will continue with the earlier one"]
问题相似，但是我这个cdc 任务没remove掉，force也不行。
今天早上缩容的cdc，现在gc还未恢复。
我想重启集群可能可以恢复，只是业务对可用想要求较高，想了解下是否有更稳妥的方式。
Ps:
cdc组件已移除，pd中已经无法查询changefeed list了，集群中目前只有1个binlog drainer组件对外同步其savepoint正常。
可以尝试把CDC扩容回来，然后把cdc 的任务remove
我感觉这个change feed删不掉是个BUG，删除后capture的owner就换一个，然后新owner继续报gcTTL错误,故障changefeed又回来了，我去提个issue问问有没有相似案例
如果集群中已经移除 TiCDC 组件，可以直接使用以下命令清除 TiCDC 遗留的 service gc safepoint:
tiup cdc:v5.1.0 cli --pd=<PD_ADDRESS> unsafe reset感谢回复，我试一下。
这样就可以移除gc阻塞了吗，还需要提个issue吗，以前有过此类问题吗？
感谢！
请问一下 这个unsafe reset 是只清理cdc 的gc信息吗？
这个应该把cdc所有元数据都重新初始化了吧
不是，这个不仅把 TiCDC GC 的信息清理了，还会把其它所有和 TiCDC 相关的任务（changefeed）信息也清理掉。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。