扩容 TIKV 节点遇到的坑

作者： david521 原文来源：https://tidb.net/blog/7fb5a77a

扩容 TIKV 节点遇到的坑

背景 ：

某 tidb 集群收到告警，Tikv 节点磁盘使用率 85% 以上，联系业务无法快速删除数据，于是想到扩容 Tikv 节点，原先 Tikv 节点机器都是 6TB 的硬盘，目前只有 3TB 的机器可扩，也担心 region 均衡后会不会打满 3TB 的盘，PD 调度策略来看应该是会根据不同存储机器的资源配置和使用情况进行 score，region balance 优先根据 leader score 和 region score 往分低的机器均衡数据来让不同节点机器的数据处于一种均衡状态，但是 PD 有时候也不是智能的，会出现偏差，导致某个节点磁盘打满也未可知，这时候就需要人为干预了，我就遇到了在不同存储节点扩容 tikv 导致小存储容量节点磁盘差点打满的情况，所以一般建议优先相同存储容量的盘进行扩容

集群环境 ：

Tidb 版本：4.0.12

Tidb: 5 节点

PD: 3 节点

TIKV：10 节点 6TB 硬盘

集群总量：45TB ，每个 TIKV 4.5TB

实施分析过程 ：

由于业务不断增长，整个集群使用率接近 80%，业务无法删除数据，于是决定扩容 tikv 节点，没有 6TB 的大盘机器，所以扩容了 1 个 3TB 的 Tikv 节点，可以考虑调整 PD 调度参数 region-schedule-limit 以及 leader-schedule-limit 来控制调度速度，调大可加快均衡速度，但是对业务会产生一定影响，过小速度会慢点，不着急的话默认值就行

扩容 TIKV

tiup cluster scale-out scale-out.yaml

扩容完成后，经过一天一夜，收到告警，新扩容的机器磁盘已经 90%

查看 PD 监控

Store Region score 差不多是 6TB 盘的一半左右，那三个 163w 的是相隔 1 天新扩容的 3 个 Tikv 节点，也是 3TB 硬盘，看的出 score 更低

这里 Store leader size 显示大小最高 4.74TB，明显大于本身 3TB 盘，显示 Store Region size 是 6.89TB ，实际硬盘使用在 2.7TB 左右，这是个疑问，为啥监控统计显示数值和实际落盘数值差距这么大，最终发现是 tidb 监控信息统计计算方式不同导致的

监控取 information_schema。tikv_store_status 这个表的信息，比如 REGION_SIZE = 所有 region 大小 * 3 副本 * 0.7（rocksdb 压缩比预估数值）

Store leader count 显示大小和已存在的 6TB Tikv 节点一样大说明基本达到均衡

Store leader score 分数已和原先的 Tikv 节点近似，此时其它节点 store leader 基本不会再迁移到本节点，但是 region score 还偏低，还会持续有其它节点数据 balance 过来，为了降低这个节点的磁盘使用率，于是开始调整 PD region_weight,leader_weight 参数来控制每个 tikv 节点的分数

pd-ctl -i -u http://ip:2379

》store

》

比如调整 Store leader score 分数已和原先的 Tikv 节点近似，说明 store leader 已均衡，但是 region score 还偏低，还会持续有其它节点数据 balance 过来，于是开始调整 PD region_weight,leader_weight，默认都是 1，比如分别调整为 0.5

》store weight 42607484 0.5 0.5

官方文档也给出说明了，因为新扩容磁盘容量大约为旧 TIKV 节点的一半，所以我暂时通过调整权重来让新扩容的节点来存储旧集群数据量的一半

调整后过 12 小时后再看，发现磁盘使用率已经降低到 70% 左右，说明参数起作用了，再逐步把 region 转移到其它机器上，慢慢达到了各个节点根据自身存储空间使数据达到均衡的目的

总结 ：

日常运维中还需要加强对 Tidb 各个组件内部调度原理的学习，不然出事难免慌张，不知所措，感谢 PingCap 提供 asktug 这个平台让我们可以搜索到很多实践运维案例，少走很多弯路