感谢感谢

我把原来备份的tiup文件修改回去了，恢复了。 生产环境没有改动过，也自动恢复了

[image] 是tiup服务器呢，之前tiup都是在这台执行的 [image]

[image] 奇怪，按照你推荐的那个方法操作后，集群不见了。但是数据库还是能进去的

[image] 还是不行

+1,我们生产也遇见了同样的问题，时间也是一样 curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh 执行以上还是无法解决

在哪里看出我这边使用了swap？

这是什么，发错了吗？

是呢，切换到另一台tidb后，到21：00切换回去，就恢复了

[image] [image] 数据库响应变慢的是持续到20：00左右

Master|root@172.16.5.174|INFORMATION_SCHEMA>SELECT * FROM cluster_slow_query WHERE Query LIKE 'SELECT b.url download_url,c.strategy_forced forced,b.version_name,b.version_code,CASE%' LIMIT 1\G *************************** 1. row *************************** INSTANCE: 172.16.5.22…

对呢，过滤了日志，OOM当天的只有1个expensive sql

[image] 你好，请问是拉长这个时间吗

[image] [image] 我们oom的时间是17：17

[image] 根据Digest在cluster_slow_query中查询出来如下： Master|root@172.16.5.174|INFORMATION_SCHEMA>SELECT * FROM cluster_slow_query WHERE Digest='daef51ee65908052cd54bf285ae71104e174e9afed92faec80f83a9ee3ebb7c5' LIMIT 1\G *************************** 1. row *************************** …

是的呢，直连单独一台TiDB的

我们的想法就是为了区分冷热数据而对表进行分区。让查询尽量少的扫描数据，进而提升SQL的查询效率。（业务上的查询是7天、15天、30天来查询的比较多，历史数据比较少查询到，所以尝试了按天分区）

[image] [image] [image] 以上是查询当时故障的那条sql. SELECT `blr`.`sourceId` FROM `bas_label_relation` `blr` LEFT JOIN ( SELECT count(pid) num,`pid` FROM `bas_label_sub_relation` WHERE ( `labelId` in(7,11,13,17,19,23,27,30,37,41,50,53,56,62,66,69,34,86,89,92,96,99,101,104,108,119,122,125,129,132,153,2,142…