TICDC 向一表一TOPIC分发数据，经常莫名卡死，不再有新的数据写入

🌞 建议反馈 产品缺陷
1

[2023/06/20 15:23:32.079 +08:00] [WARN] [client.go:259] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=19h7m33.349807365s] [role=processor]
[2023/06/20 15:23:33.079 +08:00] [WARN] [client.go:259] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=19h7m34.349760441s] [role=processor]
[2023/06/20 15:23:34.080 +08:00] [WARN] [client.go:259] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=19h7m35.350308985s] [role=processor]
[2023/06/20 15:23:35.079 +08:00] [WARN] [client.go:259] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=19h7m36.350082367s] [role=processor]
[2023/06/20 15:23:36.079 +08:00] [WARN] [client.go:259] [“etcd client outCh blocking too long, the etcdWorker may be stuck”] [duration=19h7m37.35008281s] [role=processor]
[2023/06/20 15:23:37.030 +08:00] [WARN] [collector.go:96] [“Get Kafka brokers failed, use historical brokers to collect kafka broker level metrics”] [namespace=default] [changefeed=cdc-users] [role=processor] [duration=43.774µs] [error=“write tcp 172.11.33.65:60916->172.11.13.91:9092: write: broken pipe”]

ASK上搜过有类似的问题，提示已经解决，我在版本v6.5.3 依然有此问题，请问BUG在哪个版本有修复？或者有无绕过的临时方法？？？ 这向KAFKA 分发EVENT 几乎就废了！！！

2

就没人回复吗，V6.5.4版本什么时候发布？？？

3

描述问题时候，请按照：
【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【问题现象及影响】
【复现路径】做过哪些操作出现的问题
【资源配置】

描述，尽可能提供更多有效的背景信息，很多问题在不同的场景、业务下，大家可能提供的建议是不一样的，没有讲清楚只会让大家想帮忙都无从下手~
把所有的信息描述清楚，可以更快的定位问题哟~解决问题的效率就更快哟~

4

这个报错信息是 DM（Data Migration）的报错信息，提示 etcd client 的 outCh 阻塞时间过长，可能是 etcdWorker 卡住了。这个问题可能是由于 etcd 集群出现了问题导致的，也可能是 DM Worker 出现了问题导致的。建议您先检查一下 etcd 集群的状态，确保其正常运行。您可以通过以下命令检查 etcd 集群的状态：

etcdctl --endpoints=<etcd-endpoints> endpoint status

如果 etcd 集群状态正常，那么可以尝试重启 DM Worker，看看是否能够解决问题。您可以通过以下命令重启 DM Worker：

systemctl restart dm-worker

如果问题仍然存在，建议您查看 DM Worker 的日志，看看是否有其他的报错信息。您可以通过以下命令查看 DM Worker 的日志：

tail -f /path/to/dm-worker.log

如果您需要更详细的帮助，请提供更多的上下文信息，我会尽力帮助您解决问题。

5

1、这日志来自于cdc.log，基本重启后正常一会就必现
2、dm日志没有异常
3、集群状态也正常

详见BUG #9073(https://github.com/pingcap/tiflow/issues/9073)， Fixed by #9074 这个问题好像被FIXED 但又好像没有打入V6.5.3的发布包里，虽然FIXED时间早于V6.5.3发布时间

6

看起来是 merge 到 release-7.1

7

我升级到6.5.3以后也是重启下cdc 全挂了，没有一点数据向下游写 你这边后面咋解决的？

8

可以提供 cdc 卡死时候的堆栈信息吗？ 如果可以的话，log 和监控也麻烦提供一下。

9

cherry-pick 到 6.5 的 PR 直接被关闭了，改动被包含在这个 PR 里，合到了6.5 分支， https://github.com/pingcap/tiflow/pull/9100/files#， 需要进一下分析原因。

10

升个级呗

11

6.5.3 还能往哪里更新?

12

你好，请问问题还存在吗？

  1. 能否在问题出现的时候用以下脚本抓一下 cdc 的 goroutine 信息？
#!/bin/bash

# 使用该脚本之前，你需要修改这个列表中的地址为你要下载的 cdc profile 的地址
HOSTLIST=("127.0.0.1:8300")  # 定义要连接的服务器的列表

for host in "${HOSTLIST[@]}"
do
		h=${host%%:*}
		p=${host#*:}
    echo $h $p
    # 根据 host 和端口下载三个文件
    curl -X GET http://${h}:${p}/debug/pprof/profile?second=120s > cdc.profile
    curl -X GET http://${h}:${p}/debug/pprof/goroutine?debug=2 > cdc.goroutine
    curl -X GET http://${h}:${p}/debug/pprof/heap > cdc.heap
		
		dir=$h.$p
    # 将下载的文件打包成文件夹，并将文件夹压缩成 $dir.tar.gz 文件
    mkdir $dir
    mv cdc.profile cdc.goroutine cdc.heap $dir
    tar -czvf $dir.tar.gz $dir
    rm -r $dir
done
  1. 能否提供经过脱敏之后的 cdc 日志？只需要提供 processor.go, changefeed.go 打出来的所有日志和所有 ERROR 级别的日志就足够了。
13

目前 TiCDC 仅支持同步 10 万表内的 TiDB 集群（包含最新的 6.5 版本）。可以在 changefeed 的配置中添加 [filter.rules] 过滤不必要的表，以减少同步表个数。

https://docs.pingcap.com/zh/tidb/stable/ticdc-changefeed-config

14

image
image960×425 36.2 KB

看看对应的包

15

用户您好，方便的话也提供一份出问题时间段 ticdc 的监控吧，多谢！

16

详见附件，希望能给你们提供一些帮助
dumpcdc2.log (56.6 MB)
127.0.0.1.8300.tar.gz (171.3 KB)

17

非常感谢

18

@Hacker_cjOH9cK0 请问 dumpcdc2.log 是根据某些关键字过滤过吗？我发现日志里有 Sink manager backend sink fails，但是没有 Sink manager closing sink factory，这个很奇怪，看代码是不可能发生的。如果这个日志是过滤过的话，麻烦提供一份没有过滤过的原始日志呢？

19

详见全量日志，另外这种刷屏式的错误是不是某些BUG引起的，我KAFKA集群正常的很

image
image1239×442 34.8 KB

dumpcdc3.log.gz (4.5 MB)

20

@Hacker_cjOH9cK0 收到，多谢了！另外可以暂时将 ticdc 回滚到 6.5.2 来避免这个问题。