一. 背景描述

大家在使用 TiDB 的过程中有可能会遇到 Region 和 Leader 分布不均的情况，监控信息如下：

leader 信息：

region 信息：

虽然最终解决了问题，但是整个排查及优化的过程还是很繁琐的，主要是因为架构的复杂度及对基础参数的不了解。为了方便以后对此类 region 分布不均问题的处理，结合官方文档的给出的思路整理一份排查及优化指南。

二. 官方排查问题思路

先贴一张 region 不均衡问题的官方的解释：

https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#热点分布不均匀

方方面面的都介绍的很详细了，接下来根据实际情况来捋一下排查手段及优化步骤。

三. 查看 store 打分

排查 region 分布不均的问题，第一步就是先查看 store 的打分，主要参考下面这个指标：

Store Region score：每个 TiKV 实例的 Region 分数

PD 面板 -> Statistics -> balance -> Store Region score

关于 store 的打分可以分为以下两种：

store 分数接近

打分比较接近，可以认定为均衡状态，进入以下排查流程：

1. 存在大量空 Region 或小 Region

1.1 问题排查

overview 面板 -> PD -> Region health

可以看到系统存在大量的空 region，此时我们需要开启 Region merge ，通过调度把相邻的小 Region 进行合并。开启后，PD 在后台遍历，发现连续的小 Region 后发起调度。

1.2 相关参数

PD 通过两个参数，触发 Region merge：

• max-merge-region-size

  • 控制 Region Merge 的 size 上限，当 Region Size 大于指定值时 PD 不会将其与相邻的 Region 合并。
  • 默认: 20 （单位MiB）

• max-merge-region-keys

  • 控制 Region Merge 的 key 上限，当 Region key 大于指定值时 PD 不会将其与相邻的 Region 合并。
  • 默认: 200000

1.3 操作步骤

接下来去系统中调整这两个参数：

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» config show scheduler        # 查看当前参数
    
    {
      "replication": {
        "enable-placement-rules": "true",
        "isolation-level": "",
        "location-labels": "",
        "max-replicas": 3,
        "strictly-match-label": "false"
      },
      "schedule": {
        "enable-cross-table-merge": "true",
        "enable-joint-consensus": "false",
        "high-space-ratio": 0.7,
        "hot-region-cache-hits-threshold": 3,
        "hot-region-schedule-limit": 4,
        "leader-schedule-limit": 24,
        "leader-schedule-policy": "count",
        "low-space-ratio": 0.8,
        "max-merge-region-keys": 0, #当前为0，所以没开启merge功能
        "max-merge-region-size": 0, #当前为0
        "max-pending-peer-count": 4147483647,
        "max-snapshot-count": 18,
        "max-store-down-time": "30m0s",
        "merge-schedule-limit": 8,
        "patrol-region-interval": "100ms",
        "region-schedule-limit": 80,
        "region-score-formula-version": "v2",
        "replica-schedule-limit": 64,
        "split-merge-interval": "1h0m0s",
        "tolerant-size-ratio": 0
      }
    }

» config set max-merge-region-keys 50000        # 修改 max-merge-region-keys 参数

» config set max-merge-region-size 10        # 修改 max-merge-region-size 参数

2. 热点负载问题

2.1 问题排查

查看写热点：

PD 面板 -> Statistics - hot write -> Hot Region’s leader distribution

Hot Region’s leader distribution：每个 TiKV 实例上成为写入热点的 leader 的数量

查看读热点：

PD 面板 -> Statistics - hot read -> Hot Region’s leader distribution

Hot Region’s leader distribution：每个 TiKV 实例上成为读取热点的 leader 的数量

2.2 存在热点问题

2.2.1 相关参数

如果监控出现 hot Region，但是调度速度跟不上，不能及时地把热点 Region 分散开来，这时候需要调整部分参数：

• hot-region-schedule-limit

  • 控制同时进行的 hot Region 任务。该配置项独立于 Region 调度。
  • 默认值：4

• hot-region-cache-hits-threshold

  • 设置识别热点 Region 所需的分钟数。只有当 Region 处于热点状态持续时间超过此分钟数时，PD 才会参与热点调度。
  • 默认值：3

2.2.2 操作步骤

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» config show scheduler        # 查看当前参数
    {
      "schedule": {
        "hot-region-cache-hits-threshold": 3,
        "hot-region-schedule-limit": 4
      }
    }
    
» config set hot-region-schedule-limit 8    # 通过调大这个参数，可以加快热点的调度速度

» config set hot-region-cache-hits-threshold 2    # 调小这个参数使 PD 对更快响应流量的变化

2.3 不存在明显热点

从监控上看不到明显的热点情况，但是从 TiKV 的监控可以看到部分节点负载明显高于其他节点。这是因为目前 PD 统计热点 Region 的维度比较单一，仅针对流量进行分析，在某些场景下无法准确定位热点。

2.3.1 相关调度器

可以添加 scatter-range-scheduler 调度器使这个 table 的所有 Region 均匀分布。

2.3.2 操作步骤

先定位热点所在的表：

select * from information_schema.tidb_hot_regions；

通过 curl 添加 scatter-range-scheduler 调度器：

curl -X POST http://{TiDBIP}:10080/tables/{dbname}/{tablename}/scatter

移除调度器语句：

curl -X POST http://{TiDBIP}:10080/tables/{dbname}/{tablename}/stop-scatter

这个添加调度器操作需要在业务低峰期进行，不然会影响线上性能。

3. store 软硬件差异

部分环境可能存在 tidb、tikv 所在物理机性能配置有差异的情况，可以通过参数配置控制 leader 和 region 的分布。

3.1 问题排查

通过不同机器之间的 cpu、内存、磁盘、网络等硬件的对比，以及操作系统、系统参数等环境对比。

3.2 相关参数

• LEADER_WEIGHT

  • Store 的 leader 权重
  • 默认值：1

• REGION_WEIGHT

  • Store 的 Region 权重
  • 默认值：1

3.3 操作步骤

先查看 store 的信息及默认权重：

» store    # 查看所有 store 信息

» store 5    # 这里指定查看 store 5 的具体信息，简化了部分信息
{
  "store": {
    "id": 5,
    "version": "5.1.0"
  },
  "status": {
    "leader_count": 252,
    "leader_weight": 1,     # Store 的 leader 权重参数 
    "leader_score": 252
    "region_count": 252,
    "region_weight": 1,     # Store 的 Region 权重参数
    "region_score": 39609.138540376065
  }
}

进行权重修改操作，设置 store id 为 5 的 store 的 leader weight 为 2，Region weight 为 3：

» store weight 5 2 3    

如下图，可以看到 leader 和 region 的权重已更新：

store 分数差异巨大

如果不同 Store 的分数差异较大，可以进一步观察 Operator 的生成和执行情况，这时候可以分成两种情况：

1. Operator 有调度

1.1 问题排查

通过监看查看 Operator 的相关 Metrics，确认调度室正常的。

PD 面板 -> Operator -> Schedule operator check

Schedule operator check：已检查的 operator 的次数，主要检查是否当前步骤已经执行完成，如果是，则执行下一个步骤

在调度正常的场景下，可能会出现调度速度慢的情况，可能存在以下情况：

1.2 调度速度受限于 limit 配置

PD 默认配置的 limit 比较保守，在不对正常业务造成显著影响的前提下，调大部分参数。

1.2.1 相关参数

• leader-schedule-limit

  • 同时进行 leader 调度的任务个数。
  • 默认：4

• region-schedule-limit

  • 同时进行 Region 调度的任务个数
  • 默认：2048

• max-pending-peer-count

  • 控制单个 store 的 pending peer 上限，调度受制于这个配置来防止在部分节点产生大量日志落后的 Region。
  • 默认：16

• max-snapshot-count

  • 控制单个 store 最多同时接收或发送的 snapshot 数量，调度受制于这个配置来防止抢占正常业务的资源。
  • 默认: 3

1.2.2 操作步骤

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» config set leader-schedule-limit 8

» config set region-schedule-limit 4096

» config set max-pending-peer-count 32

» config set max-snapshot-count 5

加速调度还是要考虑到服务器的性能以及业务的繁忙程度！

1.3 调度任务相互竞争

系统中同时运行有其他的调度任务产生竞争，导致 balance 速度上不去。这种情况下如果 balance 调度的优先级更高，可以先停掉其他的调度或者限制其他调度的速度。

1.3.1 相关参数

• leader-schedule-limit

  • 同时进行 leader 调度的任务个数。
  • 默认：4

• disable-replace-offline-replica

  • 关闭迁移 OfflineReplica 的特性的开关，当设置为 true 时，PD 不会迁移下线状态的副本。
  • 默认：false

1.3.2 操作步骤

假设一个场景， Region 没均衡的情况下做下线节点操作，下线的调度与 Region Balance 会抢占 region-schedule-limit 配额，此时可以调小 leader-schedule-limit ，比如从 4 改成 2：

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» config set leader-schedule-limit 2

或者打开禁止 PD 迁移下线状态的参数 disable-replace-offline-replica：

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» config set disable-replace-offline-replica true    

disable-replace-offline-replica 该参数已在 V5.0.0 版本中移除。

1.4 调度速度慢

如果遇到无理由的调度执行缓慢，这时候也可能是由于 TiKV 或者网络压力引起的：

1.4.1 相关监控

PD 面板 -> Operator -> Operator finish duration

此时的 duration 的耗时比较高，与此同时观察下 TiKV 的状态：

Overview 面板 -> TiKV -> CPU

可以看到，CPU 基本被用满了，所以调度速度上不去。

2. Operator 未生成调度

没有生成调度可以分为以下三种情况：

2.1 调度器未启用

2.1.1 未启用调度策略

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» scheduler show      # 查看调度策略命令
[
  "balance-hot-region-scheduler",
  "label-scheduler"
]

这边并未启用调度器，我们可以手动添加 balance-region-scheduler 和 balance-leader-scheduler 这两个策略：

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» scheduler add balance-region-scheduler    # 增加 balance-region-scheduler 策略
Success!
» scheduler add balance-leader-scheduler    # 增加 balance-leader-scheduler 策略
Success!

2.1.2 被部分参数限制

部分带有 limit 参数的配置如果被调成0，也有可能导致调度器不启用。

• leader-schedule-limit：同时进行 leader 调度的任务个数
• region-schedule-limit：同时进行 Region 调度的任务个数
• replica-schedule-limit：同时进行 replica 调度的任务个数
• merge-schedule-limit：同时进行的 Region Merge 调度的任务，设置为 0 则关闭 Region Merge

这些参数的值可以在 pd 命令行，通过类似 config show leader-schedule-limit 命令查看。

2.2 互斥策略

如果添加了 evict-leader-scheduler 策略，那么 PD 无法把 Leader 迁移至对应的 Store。

2.2.1 策略操作

pd-ctl -i -u http://172.XXX.XXX.XXX:2379       # 进入 pd 命令界面

» scheduler add evict-leader-scheduler 5    # 把 store 5上的所有 Region 的 leader 从 store 5 调度出去

» scheduler config evict-leader-scheduler    # 查看该调度器具体在哪些 store 上

这里演示了下打开 evict-leader-scheduler 策略，如果需要均衡 leader 和 region 的分布，一般是需要关闭这个策略，使用以下命令：

» scheduler pause evict-leader-scheduler

» scheduler remove evict-leader-scheduler

2.3 集群拓扑限制

集群拓扑的限制导致无法均衡。比如 3 副本 3 数据中心的集群，由于副本隔离的限制，每个 Region 的 3 个副本都分别分布在不同的数据中心，假如这 3 个数据中心的 Store 数不一样，最后调度就会收敛在每个数据中心均衡，但是全局不均衡的状态。

四. 总结

上面只总结了几种常见的 region 分布不均的情况，如果实际应用中遇到了其他解决不了的状况，都可以发帖寻求社区成员和 CTC 的帮助。待问题解决后，再一起把问题描述、排查思路和实操步骤补充到这篇文档中，使更多遇到问题的小伙伴受益~