谢谢反馈，这个问题目前需要用 URL encode 来转义下特殊字符，后面会考虑如何优化该问题。

对于跨云（或者跨地区）的同步，推荐以下操作： 将 TiCDC 部署到下游，是 TiCDC 到下游 TiDB 的网络延时进可能低。 打通上下游的网络，使得 TiCDC 能访问到所有 TiKV 和 PD。 这时同步速度上限取决于上下游之间网络的带宽。

麻烦用 kubectl logs -p 采集下 TiCDC Pod 重启前的日志

从监控上看 checkpoint 一直在向前推进，说明有 DDL 在同步中。目前，TiCDC 同步的 DDL 的速度较慢，所以会看到延时上升的情况，一般来说 CREATE TABLE 这种 DDL 单个的同步延时在 0.1～1 秒之间。

你好，可以上传下完整的 TiCDC 监控和所有 TiCDC 节点的日志吗？

该类日志说明 TiCDC 已经接近同步极限，v5 的 TiCDC 同步的表数有限，建议使用 v6.1 LTS 版本，会稳定很多。

TiCDC 不支持同步非 TiDB 写入的数据，也没测试过帖子中的 txnkv 的场景，不建议在生产中使用。 请问针对primary key丢失的这种情况，tikv是能自我恢复吗？ 这种有 secondary key，但没有 primary key 的事务，理论上不能自动恢复。这里恢复可能是因为这个 key 不在 ticdc 监听的 region 中了，比如分裂到其他 region 了，也有可能是被手动清理掉了。

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

TiCDC 只保证最终一致，同步期间，上下游短暂数出现据不一致是有可能的。 在这个例子中，可能是“未同步”的 changefeed 同步慢了。

可以用 git diff 来看下修改，例如想从 6.1.0 升级到 6.5.0： git diff v6.1.0..v6.5.0 cdc/sink/sink.go

TiCDC 的 kv change log 来源是 raft log，包含了对 RocksDB 的 key value 添加和删除操作。 TiKV 中的 raft log 可以近似理解为 RocksDB WAL，两者包含的信息基本一致。

没有这样的配置😥，在这个帖子之前我们还没遇到过这样的情况。 目前只能调整代码增加这配置。

processor lag 始终不为 0，是因为它的计算方式，如下 processor_lag = pd_leader_current_ts - ticdc_current_processor_checkpoint_ts 也就是 lag 是相对于 PD leader 上的物理时间的。 这种情况不需要依靠 lag 来判断，直接查看 changefeed checkpoint ts，当 checkpoint 时间戳超过开启只读的时间戳后，就说明已经完全同步了。

使用了。 没有配置。 相关代码下面的链接中，欢迎提 PR 贡献解决方案～ https://github.com/pingcap/tiflow/blob/857e7cfbe74620deb1a46a1f4cdfe383d4977fd1/cdc/sink/mq/producer/kafka/config.go#L336

方便用下面的命令抓取这两个 TiCDC 节点的 heap 消耗吗？ curl http://$CDCADDR/debug/pprof/heap > heap.$CDCADDR

该问题已在 v5.4.3 中修复，可以升级 TiCDC 看下效果。 这是 release note：https://docs.pingcap.com/zh/tidb/stable/release-5.4.3#:~:text=6198

可以是可以，但是会有一些问题，比如 1，binlog 是拿不到已经写入的数据的，需要在写入开始前就部署好 binlog。 2，binlog 会导致 tidb 一些优化失效，比如能提高写入吞吐的 async commit 和 1pc 功能。 参考 TiDB Binlog 简介 | PingCAP Docs

该图中有 “the etcd session is done”，怀疑遇到了已知问题，同步了过多的表，或者增量数据过大。如果方便的话，麻烦提供下问题时间段 11/13 12:00 到 11/13 15:00 的 TiCDC 监控面板。 同时也可以升级到最新的 v6.1.2 版本，该版本中已经解决上述问题。

调度不均衡的问题在 v6.2.0 版本之后已有优化，能自动平衡各个 TiCDC 节点上的表个数。之前的版本需要使用 API 来手动触发平衡调度，方法见 asddongmen 的回答。