遇到TiDB 5.4,日志一直报错

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.4.2
【遇到的问题】
问题一:日志中一直报错,请问如何解决:
[2023/01/06 15:46:21.745 +08:00] [ERROR] [terror.go:307] [“encountered error”] [error=“[server:8052]invalid sequence 68 != 1”] [stack=“github.com/pingcap/tidb/parser/terror.Log\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/parser/terror/terror.go:307\ngithub.com/pingcap/tidb/server.(*Server).onConn\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/server/server.go:516”]

问题二:这个集群,今天突然一瞬间内存被打满,然后tidb server io也被打满,导致无法响应业务。
image
image

问题二应该看看当时的慢SQL啊

1 Like

磁盘满了,内存也满了,明显有扫描表的动作,检查下是不是有新的sql上线。

在dashboard上没有看到特别的慢sql,但是我在日志里面看到有个比较特别的慢sql,
sql="SELECT * from parts_status\r\n where ORDER_NO in (,。。。。),这张表很小,只有几十万,但是这个in里面内容有点多,有可能是这个引起的,只有再观察下还有没有这个问题了。

你可以 参考一下这个文章,排查一下业务, 升版5.3.0之后 tidb log出现大量[ERROR] [terror.go:307] [“encountered error”] [error=EOF] - :ringer_planet: TiDB / 部署&运维管理 - TiDB 的问答社区 (asktug.com)

没有特别慢的,并发很多的查询几十万的表也很可怕,看看cpu使用率怎么样

cpu使用率很低,并且这个集群是内部系统,并发不高,目前看来最有怀疑的就是sql="SELECT * from parts_status\r\n where ORDER_NO in (,。。。。),这张表很小,只有几十万,但是这个in里面内容有点多。我们把这个改掉了,再持续观察。

内存和io瞬间打满基本肯定是sql问题了

确实是的,但是有一点奇怪的是,tikv并没有大的流量,集群也没有高的负载,如果单存是慢sql的问题,我想tikv的流量或性能一定会有特别的不一样的

这个报错是 TiDB 到其他组件连接,主动断开以后的日志输出。可以先忽略,不影响集群的正常服务和使用。

瞬间打满常见全表扫或者 Hashjoin 聚合计算在 TiDB Sever 汇聚大量数据进行计算时候,可以排查一下 slow query 中统计信息不准确或者全表扫的 Slow query ,可以参考一下查询 SQL 的问题。https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries#查询-slow_querycluster_slow_query-示例

好的 谢谢