目前集群是否部署阶段开启 TLS？ 还是已经使用一段时间开启 TLS ？TiKV 节点是否类似问题？

https://docs.pingcap.com/zh/tidb/stable/shard-merge-best-practices#上游-rds-封装分库分表的处理 这个方案是否可以做参考？

可以用 clinic 或者 metrictools 工具抓一个 TiKV-details 的监控吗？

看起来是 Kafka 下游参数配置问题，导致同步一直无法正常同步。 另外就是网络，可以从 Dainer 节点通过 telnet 检测一下下游 Kafka 的网络是否通。

是不是测试环境配置比较低，TiKV 这边处理删除操作，GC 根不上所以执行时间会比较长？ 可以看看资源负载和线程瓶颈。

是的，不过你测试为啥使用 master 版本？出现这种问题可能是初始化的有做一些调整没有进行测试。

您好，目前这块属于产品规划问题，可以等后面的相关 Meetup 或者技术沙龙来咨询解答。目前产品形态中只在 Serverless TiDB Cloud 上面有体验版本，如果感兴趣，可以通过 TiDB Cloud 申请一下开启 chat2query 来体验试用。

https://github.com/pingcap/tiflow/issues/8175 从 Github issue 来看 6.5 的确也有这个问题的。

参考最新版本的 TiDB 的 v6.5 文档 https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration ，系统变量参数配置，以 tidb_gc_* 的配置为准，之前 tikv_gc_* 是老版本的参数可以忽略哈。

如果就是 9970 的 bug，发版文档里面 5.0 版本都已经修复了。https://docs.pingcap.com/zh/tidb/stable/release-5.0.1#bug-修复

可以的，在 prometheus 上面配置就好了。另外 TiUP 部署 DM 应该会自动合并到一个 promethues + grafana + alertmanger 里面的

目前不支持，DM 仅支持 golang 标准库的正则，可以通过 re2-syntax 了解 golang 支持的正则表达式。

有确认过服务的之间时间是否同步吗 ？之前有过类似的，时间没有同步导致数据为空的情况。

目前产品中没有这块的方案，你可以在 Github 的 issue 中讨论一下这个话题 github.com/pingcap/tiflow

你现在使用的 TiKV 集群走的 TiCDC 吗？ 之前没有这个问题吧？ 可以试试最新的 tikv-client-java 的版本

dm_syncer_replication_lag_gauge 在 Prometheus 里面有记录吗？

建议参考 @xfworld 老师建议，升级一下版本

可以看一下 TiCDC 的监控情况，看看延迟主要在哪部分任务阶段上面

可以按照 grafana → Prometheus → dm-worker 逻辑向下排查看一下。常见问题可能出现在 dm-worker 和 dm-master 相关配置服务没有启动。