作者: ngvf
1. 目标:
对比 TiDB v6.0 与 v5.1.2 中 TiKV 节点重启后 leader 平衡加速,提升业务恢复速度。
2. 硬件配置:
角色 | CPU/ 内存/ 硬盘 | |
TiDB&PD | 16 核/ 16G 内存/ SSD 200G | 3 台 |
TiKV | 16 核/ 32G 内存/ SSD 500G | 3 台 |
Monitor | 16 核/ 16G 内存/ SSD 50G | 1 台 |
3. 拓扑文件配置
TiDB v5.1.2 拓扑文件参数配置
TiDB v6.0 拓扑文件参数配置
只比 TiDB v5.1.2 拓扑文件中多了 tikv : storage.reserve-space: 0MB 的参数配置,可以忽略这个参数的设置,这是一个BUG,后续官方会修复,如果您使用时没有出现就不用设置,如果想看为什么要设置 storage.reserve-space: 0MB 的详情,请看https://asktug.com/t/topic/665348/28。
4. TiUP 部署 TiDB v5.1.2 和 TiDB v6.0.0


5. 测试TiKV 节点重启后 leader 平衡时间方法
给集群 TiDB v5.1.2 和 TiDB v6.0 插入不同数据(分别是 100万, 400万, 700万, 1000万),并查看 TiKV 节点重启后 leader 平衡时间:
- 使用 sysbench 工具给集群插入数据,样例如下:
- 可通过以下这种方式查询 sbtest 数据库中 16 张表的数据统计,样例如下:
- 等待数据插入完成后,查看 Grafana 监控,所需要监控图表路径是: PD -> Statistics-balance -> Store leader count,等待各个 TiKV leader 平均后,重启其中一台 TiKV,通过 Grafana 监控图表中 Store leader count表格看 leader 平衡时间,如下图:

横坐标代表时间,纵坐标是leader的个数,不同颜色的线代表不同的tikv实例。
6. 测试结果
对比数据图

从表中对比数据得到:
- 从表格的数据看到 TiDB v6.0 TiKV 节点重启后 leader 平衡时间是 30s 的时间,比 TiDB v5.1.2 多了不少,TiDB v5.1.2 30s 出现了3次,TiDB v6.0 30s 出现了 7 次 ;
- 从表格的数据看到 TiDB v6.0 TiKV 节点重启后 leader 平衡时间 没有出现 360s,少有出现90s的时间;
<!---->
- 从表中的数据看到: TiDB v6.0 TiKV 节点重启后,不管数据多少,基本时间都是 30s 就完成了 leader 平衡(包括 30s 后少量调整的数据)。
<!---->
- 从表中也可以看到 TiDB v6.0 leader 平衡完了后,也会出现少量 leader 调整,这种情况少有。
<!---->
- TiDB v6.0 TiKV关闭后,leader 平衡时间基本上与 TiDB v5.1.2 没 变化。
以上TiDB v5.1.2 与 TiDB v6.0.0 TiKV 节点重启后 leader 平衡加速, 提升业务恢复速度的对比,是没有修改balance-leader-scheduler 策略的情况下做的,可以看到默认情况下是有提升的,如想要获取更大的加速效果,请按以下操作:
1.通过 PD Control 调整集群参数。
2.scheduler config balance-leader-scheduler介绍
用于查看和控制 balance-leader-scheduler 策略。
从 TiDB v6.0.0 起,PD 为 balance-leader-scheduler 引入了 Batch 参数,用于控制 balance-leader 执行任务的速度。你可以通过 pd-ctl 修改 balance-leader batch 配置项设置该功能。
在 v6.0.0 前,PD 不带有该配置(即 balance-leader batch=1)。在 v6.0.0 或更高版本中,balance-leader batch 的默认值为 4。如果你想为该配置项设置大于 4 的值,你需要同时调大 scheduler-max-waiting-operator(默认值 5)。同时调大两个配置项后,你才能体验预期的加速效果。
参考文档:https://docs.pingcap.com/zh/tidb/v6.0/pd-control#scheduler-config-balance-leader-scheduler
















