作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/def01f02

背景

使用某测试环境进行 POC 相关验证，测试过程中多次需要使用 tiup cluster edit-config 添加修改配置并使用 tiup cluster reload 进行重载集群。由于集群中表数量比较多，平均每个节点上的 Region 个数达到近 1 万个。不带 –skip-restart 的 reload 会按节点进行重启，节点上的 Region 数量越多，集群 reload 的时间将会越长。

由于 reload 的时间特别慢，于是手动强制停止了 reload 步骤，并换成使用 –skip-restart 的 reload 进行重载，然后再使用 tiup cluster restart 重启集群。这个步骤比滚动重启快了很多。之后在进行扩缩容操作时，为了想查看 Leader 均衡的情况，查看 Grafana 中 TiKV 的 leader 图表，发现某一个节点的 Leader 个数一直是 0，如下图所示。

分析

看到有节点 Leader 一直为 0 时，第一想法是环境是否配置了 Placement Rules，查看系统 config 后排除这种因素。于是把思路转移到之前的 reload 过程中强制停止的事件上，根据 TiDB 官网文档 术语表 | PingCAP 文档中心 说明，滚动升级过程中会产生 evict-leader-{store-id}调度，用于驱逐某个节点的所有 Leader。

根据这个信息，去 pd-ctl 中查看是否存在 evict-leader-{store-id}调度残留，果不其然。如下图所示，pd-ctl 中确实残留 evict-leader-scheduler 调度任务，使用 scheduler remove evict-leader-scheduler 移除此调度后，节点 Leader 个数开始回升，问题得以解决。

思考

此次问题的关键点在于调度。节点的 Region balance、Leader balance 等操作都是由 PD 的调度功能来完成的。PD 默认会包含相关的调度器，比如下面输出是某环境中 PD 包含的调度。

» scheduler show[  "balance-hot-region-scheduler",  "balance-leader-scheduler",  "balance-region-scheduler",  "balance-witness-scheduler",  "transfer-witness-leader-scheduler"]

除了默认包含的调度器，PD 也支持通过 pd-ctl 动态创建和删除 scheduler，比如

scheduler remove balance-leader-scheduler：删除（停用）balance region 调度器scheduler add evict-leader-scheduler 1：添加移除 Store 1 的所有 Leader 的调度器

在滚动重启过程中，可以理解为在每个节点重启的过程中动态的对当前节点进行 add evict-leader-scheduler 再 remove evict-leader-scheduler 的动作。然而，如果异常的终止了滚动重启的过程中，可能会就导致 evict-leader-scheduler 添加后未被正常的清除掉，进而引发本文中有节点没有 Leader 的现象。