搜索了下，可能是服务器时钟回调。 重启集群试试。。。

完整报错有么？

最好能保证

tidb 默认就是按照 label 自动调度的。 你先提供下上面命令信息，是不是安装配置有问题。

https://docs.pingcap.com/zh/tidb/stable/pd-control/#设置-store-weight 可以将 region 权重调大。 不过默认 region 调度是考虑磁盘的空间和使用率的。 你先提供下 lables 信息： tiup cluster display cluster-name --labels

要不发下部署集群的配置吧。

https://docs.pingcap.com/zh/tidb/stable/hybrid-deployment-topology/ 看下这个。

[image] 看你拓扑是混合部署，有做资源隔离么？是不是抢占资源 服务器资源打满了导致的。

你这报错就是 tidb 连不上 tikv 了。 结合你上面说的，服务器都连不上。应该是服务器对应时间已经连不上了。

CPU 高，应该是因为内存使用比较多，频繁触发 go gc 导致的。根本原因应该还是要看为啥内存用这么多。 [image] 看这个图片： *copr.(copIteratorWorker).handleCopCache - 17.97GB (11.16%) Coprocessor 缓存相关 sessionctx/variable.NewSessionVars - 17.56GB (10.90%) Session 变量创建 *parser/model.(ColumnInfo).Clone - 17.19GB (10.67%) 列信息克隆 session.createSessionWit…

[image] https://docs.pingcap.com/zh/tidb/stable/character-set-and-collation/

[image] 这个表表结构发下看看呢。

7.5.4 有个修复： * 修复由于查询超出 tidb_mem_quota_query 设定的内存使用限制，导致终止查询时可能卡住的问题 #55042 @yibin87 https://docs.pingcap.com/zh/tidb/stable/release-7.5.4/#错误修复 推荐集群做下升级吧。可以升级到 7.5.7

[image] mem 当时用的也很多。 对应 tidb 有一些流量： [image] 结合贴上面： [image] 主要 CPU 消耗函数 ： runtime.gcBgMarkWorker （93.15%）：后台标记工作线程，负责标记需要保留的对象 runtime.gcBgMarkWorker.func2 （92.86%）：标记过程的内部函数 runtime.gcDrain （92.71%）：处理标记队列的函数 runtime.scanobject （87.59%）：扫描对象并标记引用 runtime.findobject （32.08%）：查找对象的函数 runtime…

为啥不用 lightning tidb 逻辑模式导入呢？

这文档已经归档了 3.1 版本文档装最新版本行不通的。 官网已经放弃 docker 部署了。 可以看下 tidb-operator 来部署到 k8s.https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/tidb-operator-overview/

重启是正常操作的，只是 tidb-server 有统计信息加载机制，尤其有些表比较大，统计信息比较大可能加载会超时。。。。重启后立马接入流量是有更高概率走错执行计划的。

统计信息加载行为 tidb_stats_load_sync_wait* 作用域: SESSION | GLOBAL 是否持久化: 是 描述: 控制统计信息加载模式（异步/同步，默认 100ms超时）。 重启影响: 重启后，同步加载超时时间按配置生效。 tidb_stats_load_pseudo_timeout* 作用域: GLOBAL 是否持久化: 是 描述: 统计信息同步加载超时后是否回退到伪统计（默认 ON）。 重启影响: 超时后是否使用伪统计的策略在重启后保持。 https://docs.pingcap.com/zh/ti…

整个集群重启么？tidb-server 重启统计信息是异步加载的，可能是刚重启就接入流量，有一些 SQL 走错执行计划了？ 可以先看下对应时间是不是很多 SQL 的执行计划没有走对。