# Leader / Region 分布不均衡 - 解决方案(A)

![left](./student-guide/diagram/25-Leader-Region-solution-01-01.png)

-------------------------------------------------------------
  - 首先观察不同 Store 的打分情况

    - 如果不同 Store 的打分是接近的，说明 PD 认为此时已经是均衡状态了，此时可能的原因有：
      	- 存在热点导致负载不均衡。需要根据热点调度相关的信息进一步分析，可以参考下文热点调度的部分。
     	 - 存在大量的空 Region 或小 Region，导致不同 Store 的 Leader 数量差别特别大，导致 raftstore 负担过重。需要开启 Region Merge 并尽可能加速合并，可以参考下文关于 Region Merge 的部分。
      	- 不同 Store 的软硬件环境存在差异，如磁盘空间容量。那么可以酌情调整 leader-weight 和 region-weight 来控制 Leader / Region 的分布。
      	- 其他不明原因。也可以使用调整权重这个兜底的方法，通过调整 leader-weight 和 region-weight 来调整至用户觉得合理的分布。
      

    - 如果不同 Store 的打分差异较大，需要进一步检查 Operator 相关 Metrics，特别关注 Operator 的生成和执行情况，相关监控如下：
        - Grafana PD --> Operator --> Schedule Operator Create：Operator 的创建情况
        - Grafana PD --> Operator --> Operator finish duration：Operator 执行耗时的情况
        - Grafana PD --> Operator --> Operator Step duration：不同 Operator Step 执行耗时的情况


一种情况是生成的调度是正常的，但是调度的速度很慢
        	- 调度速度受限于 limit 配置
          	- PD 默认配置的 limit 比较保守，在不对正常业务造成显著影响的前提下，可以酌情将 leader-schedule-limit 或 region-schedule-limit 调大一些，此外， `max-pending-peer-count` 以及 `max-snapshot-count` 限制也可以放宽。
         	 - Store Limit 的配置过于保守，限制了 operator 消费的速度
        	- 系统中同时运行有其它的调度任务产生竞争，导致 balance 速度上不去
          	- 这种情况下如果 balance 调度的优先级更高，可以先停掉其他的调度或者限制其他调度的速度。例如 Region 没均衡的情况下做下线节点操作，下线的调度与 Region Balance 会抢占 `region-schedule-limit` 配额，此时我们可以把 `replica-schedule-limit` 调小将下线调度的速度限制住，或者干脆设置 `disable-replace-offline-replica = true` 来暂时关闭下线流程。
       	 - 调度执行得太慢
          	- 可以检查 Operator Step 的耗时来进行判断。通常不涉及到收发 Snapshot 的 Step（比如 TransferLeader，RemovePeer，PromoteLearner 等）的完成时间应该在毫秒级，涉及到 Snapshot 的 Step（如 AddLearner，AddPeer 等）的完成时间为数十秒。如果耗时明显过高，可能是 TiKV 压力过大或者网络等方面的瓶颈导致的，需要具体情况具体分析。

- 另一种情况是没能生成对应的 balance 调度
        	- 调度器未被启用
		比如对应的 Scheduler 被删除了，或者 limit 被设置为 0。
        	- 由于其它约束无法进行调度
		比如系统中有 evict-leader-scheduler，此时无法把 Leader 迁移至对应的 Store。再比如设置了 Label property，也会导致部分 Store 不接受 Leader。此时看到的现象是某个 TiKV 上的 leader 的数量为 0，以 evict-leader 为例：
         		 - Grafana PD --> Scheduler --> Scheduler is running：确认集群中是否存在 evict-leader 调度
          		- 使用 pd-ctl config show all 确认下存在 evict-leader 的 TiKV
          		- 使用 pd-ctl 将 TiKV 上的 evict-leader 调度 remove 掉
       	 - 集群拓扑的限制导致无法均衡
		比如 3 副本 3 数据中心的集群，由于副本隔离的限制，每个 Region 的 3 个副本都分别分布在不同的数据中心，假如这 3 个数据中心的 Store 数不一样，最后调度就会收敛在每个数据中心均衡，但是全局不均衡的状态。