看你这个任务的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

时来运转 十拿九稳 心想事成 开门见山 画蛇添足 打草惊蛇 瞠目结舌 依依不舍 11.巧舌如簧 唇枪舌剑 引蛇出洞

你上面查的是 tikv 的日志，扩容期间有这个日志是正常的，不算报错，你可以看下 cdc 的日志里有没有什么有用的信息

cdc 的报错是啥？ 你提供的信息里看起来 cdc 的状态是正常的 [image]

目前从产品层面没有硬性限制， 但是如果备份正在恢复的表，可能会导致该备份集不可用，如果使用这个备份集再进行恢复的话，查询时可能会有 Default Not Found 一类的异常。 目前内部已反馈文档优化，后续会改为：“不建议备份正在恢复的表，可能会导致备份集不可用”