tidb5.4.2系统表崩溃 SELECT * FROM INFORMATION_SCHEMA.TABLES limit 3 都卡死

[heming (何明)]

【 TiDB 使用环境`】生产
【 TiDB 版本】5.4.2
【遇到的问题】
凌晨备份日志异常 发现是 下面的报错：
dump failed: sql: SELECT COUNT(1) as c FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE=‘SEQUENCE’: invalid connection
尝试查表发现 都没响应了 。
SELECT * FROM INFORMATION_SCHEMA.TABLES limit 3;
SELECT count(1) FROM INFORMATION_SCHEMA.TABLES ;

[root@xxx-xxx223 tidblog]# grep terminated tidb.log |grep -i erro | more
[2022/09/10 10:24:09.397 +08:00] [WARN] [coprocessor.go:970] [“other error”] [conn=484791] [txnStartTS=435886730364583943] [regionID
=36387611] [storeAddr=xxx.xx.xx.158:20160] [error=“other error: Coprocessor task terminated due to exceeding the deadline”]
[2022/09/10 10:24:09.398 +08:00] [INFO] [conn.go:1117] [“command dispatched failed”] [conn=484791] [connInfo=“id:484791, addr:127.0.
0.1:58723 status:10, collation:utf8_general_ci, user:tidbdba”] [command=Query] [status=“inTxn:0, autocommit:1”] [sql=“SELECT * FROM
INFORMATION_SCHEMA.TABLES limit 3”] [txn_mode=PESSIMISTIC] [err=“other error: Coprocessor task terminated due to exceeding the deadl
ine
github.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleCopResponse
\t/home/jenkins/agent/workspace/build-common/go/src/
github.com/pingcap/tidb/store/copr/coprocessor.go:969
github.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTaskOnce
\t/ho
me/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:784
github.com/pingcap/tidb/store/
copr.(*copIteratorWorker).handleTask
\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coproce
ssor.go:668
github.com/pingcap/tidb/store/copr.(*copIteratorWorker).run
\t/home/jenkins/agent/workspace/build-common/go/src/github
.com/pingcap/tidb/store/copr/coprocessor.go:410
runtime.goexit
\t/usr/local/go/src/runtime/asm_amd64.s:1371”]
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
系统表不可用了 ，不知道会有什么影响 ，生产系统 。
凌晨1点多 DDL 还正常 。现在不太改操作DDL 11:30 会有一批DDL操作。

[h5n1]

mysql.stats_meta, mysql.stats_histograms 看下这2个表中数据条数，在看下 tidb_enable_cascades_planner 变量设置

[heming (何明)]

@h5n1

tidb_enable_cascades_planner

前面我补充了一下 tidb的错误日志 你有空看看

mysql> select count(1) from mysql.stats_meta;
±---------+
| count(1) |
±---------+
| 4031 |
±---------+
1 row in set (0.82 sec)
mysql> select count(1) from mysql.stats_histograms ;
±---------+
| count(1) |
±---------+
| 510144 |
±---------+
1 row in set (0.41 sec)

@@tidb_enable_cascades_planner |
±-------------------------------+
| 0

[h5n1]

51万看起来量也不大

[heming (何明)]

这两个语句都能成功 ， tables表 卡死了，你看看tidb的 错误信息 有没有用 。

[h5n1]

count是走的主键索引，你执行下截图中的SQL看看

[heming (何明)]

都很快 我私信您了 ，可以加个微信 方便快速沟通吗？
mysql> select count(1) from (select table_id,count from mysql.stats_meta) a;
±---------+
| count(1) |
±---------+
| 4031 |
±---------+
1 row in set (0.87 sec)

mysql> select count(1) from (select table_id,hist_id,tot_col_size from mysql.stats_histograms where is_index=0 ) a ;
±---------+
| count(1) |
±---------+
| 496678 |
±---------+
1 row in set (0.42 sec)

[h5n1]

等官方大佬来看吧

[forever]

trace 一下sql看看呢

[heming (何明)]

[heming@ansible ~]$ pd-ctl -u http://xxx.xx.xx.212:2479 store weight 1054520 0 8 跟据tidb错误日志里面的信息 调低相关tikv权重之后 现在能有点反应了 。

[heming (何明)]

怎么trace的 ，有相关的文档url吗？

[tidb狂热爱好者]

先停止tidb前端服务 再加上执行秒限制

[xiaohetao (Becky)]

集群中 LEADER-WEIGHT，REGION-WEIGHT原来的值是多少？，如果是默认值，
如下参数说明， 调整后减小这个store 上 leader 数量， 增大了 region 数量？