扩容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 这个平台让我们可以搜索到很多实践运维案例，少走很多弯路