我在本地用如下的配置启动了 kafka listeners=SASL_PLAINTEXT://localhost:9092 # Listener name, hostname and port the broker will advertise to clients. # If not set, it uses the value for "listeners". advertised.listeners=SASL_PLAINTEXT://localhost:9092 # Maps listener names to security protocols, the default is …

请问下，你们有尝试过用其他 client ，相同的用户名密码，连接过 kafka 吗？

麻烦下次如果再遇到不断打印 “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 因为这个问题一般是有某个线程卡死了才会打印，拿到线程的堆栈之后可以比较好确定问题。

这个是 TiDB 的内部错误，如果下次再遇见可以看看下游日志里面有什么报错，方便进一步排查。

这个任务同步的表数量多吗？另外添加这个任务之后 cdc 服务器的 cpu 使用量是不是打满了。 现在先确认一下到底原因是什么。 如果真的是因为增量扫数量太多导致需要排队处理，那么无法避免延迟发生，只能说也许能够降低延迟的时间。 从你提供的 puller 监控来看，每秒钟能够拉取 10 万~ 30 万行的数据，按照这个值推算，最坏需要延迟 100 分钟，可以考虑是不是能够接受。有一些参数调整也许可以加速到只延迟 60分钟左右。（不一定有用） [image] 如果无法接受，那么只能考虑放弃增量同步这部分数据了。

和这个是无关的，创建的时候随意指定同一个集群中的任意一个 cdc 都可以。 请问最后新的 changefeed 创建成功了吗？ 我指的 resolvedTs 的监控是这个： [image]

麻烦粘贴一下 TiCDC 的 dataflow 栏的监控，看看新老 changefeed 任务的 puller 是不是一直都有在持续拉数据； 然后看看每个 changefeed 的 resolvedTs 的指标的情况； 最后看看 cdc 监控下的 TiKV 那一栏下面的 CDC CPU 和 Initial scan tasks status 这两个指标。 现在的情况有可能是新的 changefeed 的增量扫数据太多，它把别的任务都饿死了，等到新建的任务增量扫结束其他任务就会推进了。

建议把 cdc 升级到 5.4.x 的最新版本

最好就是升级 cdc，要不然就只能重启，没有别的办法了。

请参考 CDC:ErrMySQLTxnError]MySQL txn error: Error 8141 - #2，来自 asddongmen 解决

请问下这个下游的 TiDB 集群是用 BR 恢复出来的吗？如果是的话可能是因为下游这行数据的索引数据在恢复的时候丢失了，需要对相关表在下游重建下索引。 执行类似如下的 SQL 来确认对应的表，然后重建索引。 select tidb_decode_key('7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8');

这个同步任务应该是无法恢复了，需要手动进行重建。 checkpoint 卡住的时间是 14:10, 但是错误的报出时间是 17:40, 看起来似乎是别的原因先导致同步中断。 这个错误的具体含义参考这里：https://docs.pingcap.com/zh/tidb/stable/troubleshoot-data-inconsistency-errors#error-8141 ，可以确认下下游 TiDB 是不是一切正常。 如果需要进一步调查确定原因，需要提供 cdc 的日志和相关时间段的监控截图。

上游大批量更新/删除数据的时候会引起 region 的 merge，这样 cdc 订阅的 region 就会产生变化，所以会有断连产生，就会打印这些日志，这是正常的。 断连之后，cdc 会向新的 region 发起请求，重新订阅，重新订阅会对 region 进行增量扫，可能会产生一定时间的延迟上升。正常情况下，延迟会自动恢复。 但是 7.1.1 有 bug 可能会在上游 region 产生变动时引起同步中断无法自动恢复，这时候可以通过手动重启 changefeed 进行恢复。 issue: TiCDC changefeed's resolved-ts is stuck · Issue #…

你好，想再次确认一下，创建 changefeed 的时候，操作的步骤是先停止 pitr, 然后用 pitr 的 restore-to 的时间作为 changefeed 的 startTs 吗？

好 感谢回复，我今天会再测试一下。

场景 2 未复现出来，请问能够提供详细的执行步骤吗？ 我是这么做的： 搭建上下游 创建 changefeed 开启 bdr 模式 更改上游 sourceID 为 6，下游改为 7 在上游插入数据 下游能够看到数据正常插入

针对场景一 ，我经过测试得出的结果如下 1. 上下游先建好 t1，t2, t3 三张表 2. 创建 changefeed，开启 bdr 模式，从源端同步到目标端 3. 插入数据到 t1 ，正常同步 4. drop table t2 5. 继续插入数据到 t1,t3正常同步 ( drop t2 不会影响 t1） 6. drop table t1 7. create table t1 8. 插入数据到 t1, 无法正常同步 9.插入数据到 t3, 正常同步（drop t1 不会影响 t3） 9. pause + resume changefeed ，恢复正常同步 场景 1 目前已找到…

你好，麻烦您提供一个拓扑图供分析。

出错之后再调整是不能恢复错误的，因为 GC 已经发生了。 可以通过 pdcli 的命令查看例如： ./pd-ctl service-gc-safepoint { "service_gc_safe_points": [ { "service_id": "gc_worker", "expired_at": 9223372036854775807, "safe_point": 444539433238396928 }, { "service_id": "ticdc-default-15674009460217235928…