TiKV 节点重启后业务恢复速度（leader 平衡速度）v6.0 vs v5.1.2 对比测试

作者： ngvf 原文来源：https://tidb.net/blog/0cbf5031

1. 目标:

对比 TiDB v6.0 与 v5.1.2 中 TiKV 节点重启后 leader 平衡加速，提升业务恢复速度。

2. 硬件配置:

3. 拓扑文件配置

TiDB v5.1.2 拓扑文件参数配置

server_configs:  pd:    replication.enable-placement-rules: true  tikv:    server.grpc-concurrency: 8    server.enable-request-batch: false    storage.scheduler-worker-pool-size: 8    raftstore.store-pool-size: 5    raftstore.apply-pool-size: 5    rocksdb.max-background-jobs: 12    raftdb.max-background-jobs: 12    rocksdb.defaultcf.compression-per-level: ["no","no","zstd","zstd","zstd","zstd","zstd"]    raftdb.defaultcf.compression-per-level: ["no","no","zstd","zstd","zstd","zstd","zstd"]    rocksdb.defaultcf.block-cache-size: 12GB    raftdb.defaultcf.block-cache-size: 2GB    rocksdb.writecf.block-cache-size: 6GB    readpool.unified.min-thread-count: 8    readpool.unified.max-thread-count: 16    readpool.storage.normal-concurrency: 12    raftdb.allow-concurrent-memtable-write: true    pessimistic-txn.pipelined: true  tidb:    prepared-plan-cache.enabled: true    tikv-client.max-batch-wait-time: 2000000

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 平衡时间：

1. 使用 sysbench 工具给集群插入数据, 样例如下：

2. 可通过以下这种方式查询 sbtest 数据库中 16 张表的数据统计, 样例如下：

3. 等待数据插入完成后，查看 Grafana 监控，所需要监控图表路径是: PD -> Statistics-balance -> Store leader count，等待各个 TiKV leader 平均后，重启其中一台 TiKV，通过 Grafana 监控图表中 Store leader count 表格看 leader 平衡时间，如下图:

横坐标代表时间，纵坐标是 leader 的个数，不同颜色的线代表不同的 tikv 实例。

注:tikv 是作为一个进程服务在节点上,所以可以通过 systemctl 管理 tikv 服务的启动、重启、停止、重载、查看状态命令；标题中的重启可以通过 systemctl stop tikv-20160.service 和 systemctl start tikv-20160.service 模拟实现。

6. 测试结果

对比数据图

从表中对比数据得到:

1. 从表格的数据看到 TiDB v6.0 TiKV 节点重启后 leader 平衡时间是 30s 的时间，比 TiDB v5.1.2 多了不少，TiDB v5.1.2 30s 出现了 3 次，TiDB v6.0 30s 出现了 7 次 ；

2. 从表格的数据看到 TiDB v6.0 TiKV 节点重启后 leader 平衡时间 没有出现 360s，少有出现 90s 的时间；

1. 从表中的数据看到: TiDB v6.0 TiKV 节点重启后，不管数据多少，基本时间都是 30s 就完成了 leader 平衡（包括 30s 后少量调整的数据)。

1. 从表中也可以看到 TiDB v6.0 leader 平衡完了后，也会出现少量 leader 调整, 这种情况少有。

1. 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）。同时调大两个配置项后，你才能体验预期的加速效果。

>> scheduler config balance-leader-scheduler set batch 3  // 将 balance-leader 调度器可以批量执行的算子大小设置为 3

参考文档：https://docs.pingcap.com/zh/tidb/v6.0/pd-control#scheduler-config-balance-leader-scheduler