[image] 上游的这个 region 有问题，它一直没有解锁。 可以尝试使用这个这个 issue 里的 step3 来对这个 region 进行解锁。

嗯 对，你把 CheckpointTs 记录下来，重新创建两个任务。

你好，建议使用 filter rule 把这张表单独使用一个 changefeed 进行同步，剩余其他的表用另一个 changefeed。 这样做可以让其他表的同步进度得以推进，并且减少同一个 changefeed 内多表之间资源的竞争。 麻烦提供一下上游 tikv 集群的 region 数量。

你好，请问问题解决了吗？你可以尝试： 检查 ticdc 机器到目标 tidb 集群机器的网络延迟。 如果网络延迟没有问题，能不能麻烦上传 ticdc 的日志和 Grafana 监控面板中 TiCDC Dashboard 中的 Sink 和 Dataflow 的相关指标，以便帮助我们排查问题。 如果网络延迟有问题，可以考虑把 TiCDC server 部署到目标 TiDB 集群的环境中，这样能够一定程度缓解网络延迟造成的同步缓慢问题。

你好，现在是不支持这个功能的。

支持库基本的同步，可以利用 filter rule 指定 changefeed 需要进行同步的库。建议每个同步任务同步的表的数量不要超过1000 张。 同步进度一直卡主不动是因为有 100GB 的存量数据需要先拉过来，才能进行同步。 TiCDC 目录下的文件已经超过 130GB 是因为需要把拉过来的数据进行排序。 这个增量数据太大是否有影响：是的，增量数据太大可能会让同步任务在初始化完毕之后卡住很长一段时间。

请问磁盘配置是什么样的呢？

麻烦试试拉取最新的 master 代码，然后再 make 试试。

建议先检查 sink-uri 中的用户名和密码是不是正确指定为下游的用户名和密码。 经过第 1 步之后，如果仍然连接失败，考虑先将密码转义再试。

你好，这个报错的意思是一个 changefeed 包含的元数据信息已经超过了单个 etcd 事务能够处理的大小。该问题应该是一个 changefeed 同步太多张表引起的，请问你一个 changefeed 同步了多少张表呢？ 如果不愿意升级 cdc 版本，那么可能的解决方案如下： 记录当前 changefeed 的 checkpointTs。 停止上游 tidb 集群的 gc 。 删除掉 etcd 内该 changefeed 的元数据。 启动新的同步任务，设置 startTs 为刚刚记录的 checkpointTs，并且每个 changefeed 不要同步超过 500 张表。 目前这个…

原因：创建 changefeed 的时候，cdc 会通过真实的创建一个到下游 kafka 的连接来验证是否用户所提供的 sink-uri 是否能够成功的连接到下游，然后把连接关闭。在关闭该验证用连接时，就会出现该日志。 因此不用关心它。

不好意思我说错了，6.2.0 不能换成 6.1.2 ，麻烦你用 v6.3.0 。

changefeed 要同步的表会以 table 数量为单位分配到不同的 capture 上进行同步。 对于你遇到的问题，麻烦你执行一下 ./cdc version 命令获取 cdc 的版本信息，然后粘贴上来帮助我们排查。 按理来说 cdc 应该会自动对表进行负载均衡，如果它没有自动负载均衡， 可以通过 openAPI 来主动让它进行调度，参考：https://docs.pingcap.com/zh/tidb/dev/ticdc-open-api#手动触发表的负载均衡 如果以上方法不管用，可以考虑暂停并重启 changefeed。 如果上述两个方法都没有用，最后考虑重启 cdc ow…

目前怀疑是该 bug 导致，你可以尝试使用 v6.1.2 cdc 。

能帮忙在出现该问题的时候抓一下 profile 吗？ curl -X GET http://${host:port}/debug/pprof/profile?second=120s > cdc.profile # 抓取 cpu 采样时间 120s curl -X GET http://${host:port}/debug/pprof/goroutine?debug=2 > cdc.goroutine # 抓取 goroutine curl -X GET http://${host:port}/debug/pprof/heap > cdc.heap # 抓取 heap

请问下这个你需要同步的库里面有多少张表？ 5.2.1 版本 TiCDC 同步的表总数量建议不要超过 1.5k 。

Q1. 这种情况下应该怎么调优cdc节点呢？ 如果你是用的 TiCDC 是 6.1.0 版本，可以尝试一下使用 6.1.2 版本。6.1.2 对大事务有相应的优化。 300 多个字段的大单表，6.1.0 版本的 cdc 编码速度较慢，确实会导致同步速度跟不上的情况。可以考虑把那一张大单表单独使用一个 changefeed 进行同步，因为它可能拖慢了其它表的同步进度，并且也可以加快对该表消息的编码速度。 Q2. 同一个表，建立两个测试任务同步到不同kafka，cdc端抽取延迟也不同，这是为什么呢？ 可能是不同 kafka 的网络速度不一样，可以观测一下写到不同 kafka 的 chan…

创建 changefeed 的时候，cdc 会通过真实的创建一个到下游 kafka 的连接来验证是否用户所提供的 sink-uri 是否能够成功的连接到下游，然后把连接关闭。在关闭该验证用连接时，就可能会出现该日志。 如果 changefeed 创建成功并且正常同步，可以忽略这个告警。 如果 changefeed 没有正常同步，麻烦提供更多的日志或者监控截图以供进一步排查问题。

麻烦提供一下 TiCDC 的版本号。 请问 TiCDC 监听的集群表的数量和 region 数量大致是多少？ 有没有 cdc 的监控或者日志可以提供一下，可以帮助我们更好地分析和排查问题。 如果可以的话，建议把 cdc 单独部署到一个节点，因为 cdc 和 tidb 的热点时间是会基本重合的。