作者：顧大偉
擴容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 轉移到其它機器上，慢慢達到了各個節點根據自身存儲空間使資料達到均衡的目的