当前一个 cdc 任务卡主其他任务是不预期的。是 5.1 版本已知问题，需要升级。6.5以上版本解决 cdc 对表 id 较多的情况，初始化 & 调度是串行的，导致 8w+ 个表的元信息加载时间很长，导致新建任务一直在初始化。6.5-7.1 有优化，7.5 彻底解决。 解决方案： 升级集群到新版本 不能升级的话： 停止 CDC 进程 当前正常删除任务方法不行，使用 etcdctl 直接删除 pd 中 cdc 相关元信息。 删除后拉起 cdc 服务即可 后续需要对同步任务拆表处理，推荐一个任务不要超过 2000 个 table id。 推荐： 低版本比如 5.1 可以考虑试试…

[image] 感觉确实是 pd 访问不了 tikv 触发了什么熔断机制。做 leader 驱逐。tidb 自我熔断了。。。减少影响。

发下完整的 pd leader log 。感觉触发了机制的话应该有相关关键字。

执行计划不一样.dat (16.5 KB) 新老版本执行计划不同的点。后面用 hint 解决的： explain SELECT /*+ LEADING(rs,om,ro) */ count(1) AS refundCount FROM TCSceneryMemberOrderAll.RefundSupplier rs INNER JOIN TCSceneryMemberOrderAll.OrderMain om ON om.SerialID = rs.SerialID INNER JOIN TCSceneryMemberOrderAll.RefundOrder…

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#isolation-read 配置这个就行了。

用 tiup patch 功能，当个补丁打。 不过不推荐。

正常来说不会存很多东西 。节点比较多？ 感觉可以试试升级 。6.1.0 版本太低了，第三位最好拉平最新版本。

低版本盘满是有这个问题。 扩缩容修复下？ 升级吧。4.x 太老了，而且对于盘满的情况 新版本有优化。专栏 - TiDB 新特性解读 （6.0~6.6） | TiDB 社区

看下系统日志，是不是硬件坏了。

目录被删了？

是不是单服务器多实例部署了，但是没有打 label？

问题解决了么？

就这个问题来说，数据库不需要重装或者处理什么。 看起来升级内核解决了，这个一般是硬件和系统内核的兼容性/bug 问题。

后续 tispark 其实基本不推荐使用了。 第一个告警是因为默认去 hive 拿数据。

2 中 tidb 没有 txnlockfast 关键字应该是因为你们配置了 max execute time，SQL 被 kill 了，没有到 txnlockfast backoff 记录的代码逻辑，你们可以 execute time 限制去掉，来观察和排查。 调整悲观事务，可以试试，但是收益不一定大。 减小事务的大小，特别是减少事务中的写操作数量，可以有效减少冲突和锁等待时间 虽然 TiDB 4.0 默认使用乐观锁，但在高冲突场景下，你可以考虑适当的业务逻辑调整或在应用层实现重试逻辑。 所以还是先去掉 execute time 限制，看看 tidb.log 能不能找到相关信息，优…

那就有点懵圈了，讲道理 pd 这部分逻辑和你手动 curl 没有区别的。

那不应该啊 ，我看日志是获取 member list 不行，但是手动又可以。你试试手动掉这个 API 有内容么： 2024/04/16 10:04:56.799 log.go:85: [warning] etcdserver: [could not get cluster response from http://10.172.65.146:23802: Get "http://10.172.65.146:23802/members": dial tcp 10.172.65.146:2380 2: connect: connection refused] [2024/04/16 10:04:…

pd-ctl 进去，敲下 member 里面信息文本方式发出来我瞅瞅呢。

[image] 为啥 151 上有两个？