一、现象描述
在一个平平无奇的下午收到告警，登录到监控进行查看：
Overview -> Tikv -> leader
Overview -> Tikv -> region
通过观察 leader 和 region 的面板，我们发现某 TiKV 节点的 leader 被驱逐，leader 数量呈断崖式下降，最终 leader 被全部驱逐。但与此同时，该期间 region 数量正常变化，这是令人比较诧异的一个现象。
到这里，我们还不能判断是什么原因导致的这一现象，下面继续分析。
二、问题排查
2.1 IO 被打满
Overview -> System Info -> IO Util
到这里，我们看到某节点磁盘利用率被打满过，该节点上混部了我们的一个 TiDB 和 一个 PD 。
2.2 查看该机器日志
在这里发现了 kernel 级别的错误，controller encountered a fatal error and was reset，表示某个硬件控制器出现了严重错误并被重置。
2.3 PD 集群 Leader 切换
Overview -> PD -> Region health
随后观察 PD 的 Region health 监控，发现告警后的数据没有显示，除此之外还有其他面板有相似的情况：
通常来说，TiKV 节点会将这些信息上报给 PD 集群中的 Leader 节点。因为在 PD 集群中，Leader 节点是负责处理所有数据调度操作的。所以，这里猜测 PD 集群中的 Leader 节点发生了切换。
后面通过 tiup cluster display 集群名称 以及 监控：Overview -> PD -> PD role 发现，PD 集群的 Leader 节点确实进行了切换。
截止到这里，关于某个 TiKV 节点的 leader 被驱逐的原因还是没有被分析出来，不过既然得知 PD集群 Leader被切换也算是稍有眉目了。
2.4 查看 PD 日志
旧 Leader 节点的日志：
leader failed to send out heartbeat on time; took too long, leader is overloaded likely from slow disk。 Leader 节点没有在预定的时间内发送出心跳信息，发送心跳信息所需的时间过长，可能是因为 Leader 节点的磁盘响应速度过慢，导致了过载。
pd leader election，紧接着 PD 集群开始的 Leader 的选举。
新 Leader 节点的日志：
同样，我们看到了 send keepalive message fail, store maybe disconnected ，PD 给 Store 发送信息失败，认为其有可能失去连接。
除此之外，在它 "晋升" 为 Leader 后 对某个 Store 添加了 evict-leader-scheduler 的任务。
2.5 及时解决
- 既然是由于 evict-leader-scheduler 造成的，我们只需要执行 scheduler remove evict-leader-scheduler 即可。
-
在有资源的前提下，考虑将 TiDB 和 PD 分开部署；资源有限的前提下，将 TiDB 和 PD 部署到同一台机器的不同磁盘上，降低风险。
-
当前版本为 V5.4.3，后续也考虑将集群进行升级，规避一些未知风险。
三、总结
根本原因是系统级别的磁盘 Kernel 故障，带来了一系列影响。首先是 PD 集群的 Leader 角色磁盘负载升高，导致 Leader 进行切换，之后对某个 Store 节点上的 Region 的 Leader 角色进行了驱逐，产生告警。
首先，我们要肯定 PD 切换 Leader 这一操作是十分正确的。但对于为某个 TiKV 节点添加 evict-leader-scheduler 这一操作还是有疑惑的，有可能是因为 V5.2.0 起，TiKV 引入了慢节点检测机制导致的，导致我们的 PD 集群的 Leader 切换后，觉得某个 TiKV 慢，从而进行了 Region 的 leader 驱逐。并且我们针对 leader 被驱逐的 TiKV 做了检测，并未发现存在硬件问题。后续也期待官方在 TiKV 慢节点检测这方面的优化。
除此之外，在整个切换过程中，业务感知良好，没有产生很大影响，也验证了 TiDB 高可用性的强大，手动点赞。