背景

使用某测试环境进行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的现象。