【SOP 系列 19】region 分布不均问题排查及解决不完全指南

一. 背景描述

大家在使用 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

image

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

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-schedulerbalance-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!

image

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 的帮助。待问题解决后,再一起把问题描述、排查思路和实操步骤补充到这篇文档中,使更多遇到问题的小伙伴受益~

13 个赞

前排围观啊~ :ghost:

1 个赞

后排入座

今天前排就一排。。。vip包间围观

1 个赞

你说的这些pd-server的参数调整。我看tidb v5.1.0 默认已经开了,数值方面确实有细微的差别,这是什么版本tidb怎么都没开。
不过思路还是很有学习的必要的。

1 个赞

初始版本是v5.0.0-RC,目前是v5.1.0。

升级路线是:v5.0.0-RC -> v5.0.0 -> v5.0.1 -> v5.0.2 -> v5.1.0

在加一个 → 5.1.1 :nerd_face:

:ok_hand:

insert大量有自增长字段数据时 也可能会 导致 hot region

1 个赞