你不用 盯着某一条看， 如果是小概率发生， 抓包也不一定能抓得到， 看下 sql statement 里面这条 select 1 的 sql 平均执行时间，中位数分别是多少？ 是不是只有很少量的 select 1 执行的慢

[image] 看下 日志里有什么信息

我只是举个例子，现在真实情况是慢日志没有正常被记录，你可以看看 tidb本身的日志，或者系统日志能不能找到具体原因

[image] 从监控看 13:50 之后就没记录慢日志了， 从慢查询页面也找不到任何慢日志记录，可以看下 tidb-server 的日志，是不是空间满了之类的原因导致慢日志没有正常被记录

看你这个任务的sink uri 并没有指定 kafka-version 呢

把日志贴完整吧，具体有用的信息应该在下面

cdc cli changefeed query 看下完整的cdc配置，发出来看看

你说的同步任务报错只有 kafka 这个报错吗？ kafka-version 错误只是其中一个可能，可以看下下游 kafka 日志中有没有更多信息

不停 tikv 节点的话，不用考虑 max-store-down-time ，注意前面的业务别连到 停掉 的 tidb-server 即可

可以尝试切换一个 PD 节点运行 dashboard 试试 参考文档: https://docs.pingcap.com/zh/tidb/stable/dashboard-ops-deploy/#切换其他-pd-实例提供-tidb-dashboard-服务

TiCDC 是监控 tikv 的 change log的，其中 OwnerDDLPuller 可以监听上游元数据的变化和 DDL 事件， tikv-java-client 应该也能实现类似的功能，不过还是推荐用 TiCDC 这种成熟的产品，兼容性肯定更好 你下游是什么数据库？ Pulsar 可以用吗？

TiCDC 有专门的 OwnerDDLPuller 去拉取上游的 DDL， 你的使用场景是啥？ 直接用 TiCDC不行吗？

是稳定复现吗？ 这个 noteid 字段里的字符串最近涉及变更吗？ 比如是刚insert 进来的？还是update 过的？

监控看下 blackbox 页面，看看 pd 机器的 ping 延迟情况如何？

tidb.log 中应该有更详细的堆栈信息，不过你这个版本太老了， 建议早点升级到 v7以上的版本吧

not leader 有可能是由于集群中的 region 调度导致的，并不会直接导致 cdc 卡住， 看监控是延迟了一小时左右恢复的，是人工干预了还是自己恢复的？

自动的话要根据 tidb_auto_analyze_start_time 和 tidb_auto_analyze_end_time 参数决定的。 建议你手动收一下最好

看了你的执行计划，新版本集群主要是慢在这里，且统计信息是过期的，看起来是统计信息不准导致的执行计划估算错误，建议手动全量收集统计信息 [image] [image]

admin check 校验一下表和索引看看呢 https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index#admin-check-tableindex