又错过了

应该不是呢，网络带宽什么都不高。目前没有内网延迟和丢包的监控。这个不好说 问题应该还是磁盘IO的问题 从云主机监控看到那个点 磁盘IO等待很长 [image]

没有呢，除了虚拟机本身的进程外，就是tikv和自带的monitor了

嗯看到磁盘读延迟很高，但是系统盘和数据盘都很高

嗯，目前看到是这个节点的磁盘iowait有点高， 读延迟那会增大了很多 [image] 而且系统盘和数据盘读延迟都很高。tikv节点是部署在系统盘的，所以服务的日志写入是系统盘，数据存储是独立的数据盘。 为啥是两个都高呢？ 带宽流量也没有出现突增的情况 [image]

没有看到pd leader切换的日志

从监控看磁盘iops下降是结果，不是原因 [image] 出现问题之前，cpu iowait 开始有点高

存储空间是足够的，也没有收到相关报警

1、你们在数据库选型的时候看了哪些数据库？ percona、mysql、tidb 2、最后为什么选择了 TiDB ？原因是什么？ 最主要的原因有两点： 2.1、解决我们日益增长的分库分表问题（商品库表超级大，单MySQL实例已经无法满足，不得不采用复杂的分实例、分库、分表） 2.2、有好的动态扩缩容，不用是存储还是计算。都可以做到按需对业务几乎无感知的扩缩容 另外个人觉得tidb的官方论坛很值得点赞，遇到问题的时候在这里寻找问题答案或者咨询问题，都能很快、很好的得到回复，得到解决方案。这也是在公司内部推荐推进tidb的一个原因 目前生产已经部署两套tidb集群，其余MySQL实例…

昨天清理了dm-cluster集群，今天再缩容server节点没有遇到该问题，估计是dm相关导致的。

没有呢，基于 Test-Cluster关键词没有匹配到任何记录

嗯，目前dm不用了，我把这个卸载了，等下次server节点扩缩容的时候再看

历史确实部署过dm组件，不过这个集群好长时间没有动过了，而且这个集群的迁移结束再五月份，期间也对tikv/server做过扩容和缩容，第一次遇到这个名字变更的 刚从 .tiup 下dm的审计日志中看到也确实有 Test-Cluster的关键字，不过都是2024年的日志了

从grafana prometheus等日志都没有发现这么个名字

最终是如何解决的呀？

哈哈哈，跟着你们的回答确实能学到很多知识点呢

嗯嗯，赶紧去搜了下学习了解中

还是你呢，我排队学习

搬凳子等回答中… 第一次听到RU的概念