ticdc 删除 changefeed 时，owner 节点变为 Processor 节点

[Mwkk (Ti D Ber A Cla Yr Lb)]

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

在 21:54 时间左右对3个 ticdc 节点进行了 打 patch，升级到 v7.1.6 ，在22:03 执行了清理 changefeed 的命令cdc cli changefeed remove --server=http://xx.xx.xx.xx:xxxx --changefeed-id lego-level-tianji-bk owner 节点变为 processor 节点，
日志提示 [WARN] [client.go:271] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=2m44.998942131s] [role=owner]
cdclog.zip (4.9 MB)

[Mwkk (Ti D Ber A Cla Yr Lb)]

在22:08 依次对3个节点进行了重启操作，选举出了一个 owner 节点。

[Jellybean (李文杰)]

owner的切换总体上不会影响同步任务的后续管理的，请问是遇到了什么问题

[Mwkk (Ti D Ber A Cla Yr Lb)]

现在想把一个 changefeed 删除掉，执行 remove 命令的时候，日志一直提示 etcd 的工作线程 卡住，owner 节点变为 processor 节点，同一集群的另一个 changefeed 受到影响

[kkpeter (Upstream889)]

是从哪个版本升级到v7.1.6的

[Mwkk (Ti D Ber A Cla Yr Lb)]

7.1.5

[kkpeter (Upstream889)]

你们CDC几个节点

[Mwkk (Ti D Ber A Cla Yr Lb)]

3节点

[wlwilliamx]

不好判断是什么问题导致的，能否采集一下出问题前后一小时的 clinic，这会很有帮助，可能可以帮助 TiCDC 发现一些新问题。

[Mwkk (Ti D Ber A Cla Yr Lb)]

可以的 ，我打一下日志

[这里介绍不了我 (持续学习)]

我也碰见过，突然没有 owner 了，同步卡住，后面 ticdc 我就挨个重启就正常了

[Mwkk (Ti D Ber A Cla Yr Lb)]

现在主要问题是想清理 changefeed 任务，有个 changfeed 做为主从集群的，这个checkpoint 基本推进不动，想改配置重启它 ，直接没有 owner ，就打算重做从集群和同步链路，现在卡在这了

[这里介绍不了我 (持续学习)]

没有 owner ，我记得任何操作执行都没反应

[Mwkk (Ti D Ber A Cla Yr Lb)]

是的，日志一直提示 etcd 的线程卡住

[这里介绍不了我 (持续学习)]

是的 我是重启解决 不断重启

[Mwkk (Ti D Ber A Cla Yr Lb)]

Download URL: Clinic Service 已上传，麻烦帮忙分析一下

[asddongmen (dongmen)]

麻烦下次如果再遇到不断打印 “etcd client outCh blocking too long, the etcdWorker may be stuck” 这个日志，帮忙用如下命令抓一下对应 cdc 的 goroutine 。

curl -X GET http://127.0.0.1:8300/debug/pprof/goroutine?debug=2 > cdc.goroutine 

因为这个问题一般是有某个线程卡死了才会打印，拿到线程的堆栈之后可以比较好确定问题。

[Mwkk (Ti D Ber A Cla Yr Lb)]

好的，下次遇到这样的问题 打下 goroutine

[WalterWj (王军 - PingCAP)]

总结：

1. 目前怀疑是 NAS 硬盘速度慢导致删除 redo log 很慢
2. 由于删除 redo log 是在 owner 的 Tick() 里前台执行的，这一步慢就会直接卡住 Tick()
3. Grafana 的 Ownership history 是统计 owner 的 Tick() 是否有按时执行，所以 Tick() 卡住就会显示为 ownership = 0，虽然选举意义上的 owner 实际上没有变化

相关日志：

Jul 22, 2025 @ 17:05:26.437 ["handle admin job"] [changefeed=lego-level-tianji-bk]
Jul 22, 2025 @ 17:05:26.444	["redo manager write deleted mark"] [namespace=default] [changefeed=lego-level-tianji-bk]
Jul 22, 2025 @ 17:07:00.286	["changefeed closed"] [namespace=default] [changefeed=lego-level-tianji-bk]

应该就是这个 RemoveFilesIf 慢了。这个 etcd client outCh blocking too long 日志就持续了 1 分多钟，看日志里，从 cdc owner handle 到结束就是 1 分多钟，redo manager write deleted mark 的日志很快就输出，之后就卡住了 1 分多钟。问了一下 team 的人，大概率是 redo 这里慢了，因为之前出现过。
执行比较慢，其实任务已经提交到 cdc 了，但是因为太慢了，导致 client 触发超时直接返回了，但是 cdc 内部是在执行这个任务的