你好，想再次确认一下，创建 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…

需要写，建议按照对应版本的官方文档操作。

非常感谢

你好，请问现在 cdc 能够恢复同步了吗? 能否在卡住的时候用以下脚本抓一下 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}…

你好，请问问题还存在吗？ 能否在问题出现的时候用以下脚本抓一下 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/…

下游是什么？看看监控写下游的延迟。 能不能多贴一些监控指标，比如 dataflow 那一栏的指标。 看看 lag analyze 那一栏的监控。 ResolvedTs 推进吗？还是一样的卡住了。 看看日志有没有什么报错，有没有 “too long” 关键字。 如果可以，希望您可以提供脱敏后的日志供排查，谢谢。

[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 试试。