TiDB大規模節點下線實踐

1、 背景

集羣容量不夠了，這些年各大公司都在作機器資源利用率的事情，我司也不例外，好不容易申請了5臺機器加入集羣擴容，balance的正歡樂呢，Region Balance Ratio通過了1天半的時間剛剛降到93%，結果接到通知，5臺機器的交換機升級，需重啓機器，網卡要作bond。

集羣配置

集羣版本：v3.0.5
集羣配置：普通SSD磁盤，128G內存，40 核cpu
tidb21 TiDB/PD/pump/prometheus/grafana/CCS
tidb22 TiDB/PD/pump
tidb23 TiDB/PD/pump
tidb01 TiKV
tidb02 TiKV
tidb03 TiKV
tidb04 TiKV
tidb05 TiKV
tidb06 TiKV
tidb07 TiKV
tidb08 TiKV
tidb09 TiKV
tidb10 TiKV
tidb11 TiKV
tidb12 TiKV
tidb13 TiKV
tidb14 TiKV
tidb15 TiKV
tidb16 TiKV
tidb17 TiKV
tidb18 TiKV
tidb19 TiKV
tidb20 TiKV
wtidb29 TiKV
wtidb30 TiKV
wtidb31  新加入的TiKV
wtidb32  新加入的TiKV
wtidb33  新加入的TiKV
wtidb34  新加入的TiKV
wtidb35  新加入的TiKV

縮容流程：

縮容 TiKV 節點
例如，若是要移除一個 TiKV 節點（node9），IP 地址爲 172.16.10.9，能夠進行以下操做：
1. 查看 node9 節點的 store id：
/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store
2. 從集羣中移除 node9，假如 store id 爲 10：
/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store delete 10
2. 使用 Grafana 或者pd-ctl檢查節點是否下線成功（下線須要必定時間，下線節點的狀態變爲 Tombstone 就說明下線成功了）：
/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store 10
3. 下線成功後，中止 node9 上的服務：
ansible-playbook stop.yml -l 172.16.10.9
4. 編輯inventory.ini文件，移除節點信息：
[tidb_servers]
172.16.10.4
172.16.10.5

[pd_servers]
172.16.10.1
172.16.10.2
172.16.10.3

[tikv_servers]
172.16.10.6
172.16.10.7
172.16.10.8
#172.16.10.9  # 註釋被移除節點

[monitored_servers]
172.16.10.4
172.16.10.5
172.16.10.1
172.16.10.2
172.16.10.3
172.16.10.6
172.16.10.7
172.16.10.8
#172.16.10.9  # 註釋被移除節點

[monitoring_servers]
172.16.10.3

[grafana_servers]
172.16.10.3
如今拓撲結構以下所示：
    Name    Host IP Services
    node1   172.16.10.1 PD1
    node2   172.16.10.2 PD2
    node3   172.16.10.3 PD3, Monitor
    node4   172.16.10.4 TiDB1
    node5   172.16.10.5 TiDB2
    node6   172.16.10.6 TiKV1
    node7   172.16.10.7 TiKV2
    node8   172.16.10.8 TiKV3
    node9   172.16.10.9 TiKV4 已刪除
5.更新 Prometheus 配置並重啓：
ansible-playbook rolling_update_monitor.yml --tags=prometheus
打開瀏覽器訪問監控平臺：監控整個集羣的狀態

balance狀況

由於balance速度過大會影響業務，此時新加入的5臺機器經歷近兩天的時間，region balance剛降至93.9%

2、實戰演練

咱們對TiKV實例執行縮容操做，正常下線都是一個個下的，當時我是5個一塊兒執行的命令，好在並無什麼異常狀況出現，不過並不推薦~
如今狀態都是"state_name": "Offline"，沒有變Tombstone 
狀態含義

在下線的過程當中，須要遷移region，以前遷移了一天才降低5%還得反遷移回去，當時是93%差很少快2天了，執行後能夠看到region balance和leader balance都反向增加

異常狀況
咱們發現下線遷移balance過程當中，速度愈來愈慢

官方手冊有以下一段話：

例如 Region 沒均衡的狀況下作下線節點操做，下線的調度與 Region Balance 會搶佔 region-schedule-limit 配額，此時你能夠調小 replica-schedule-limit 以限制下線調度的速度，或者設置 disable-replace-offline-replica = true 來暫時關閉下線流程。

27號14點後速度放緩,按照手冊中的說明，調大replica-schedule-limit 能夠加快下線調度速度，爲了加快遷移速度，儘快下線，咱們調大了該參數到32。

此時能夠看出，調度確實有了明顯的增長，可是僅僅持續了沒多久，咱們發現調度速度又變慢了，這是爲何呢，實際上是由於調度爭用致使的。

咱們可以經過下圖看出，replace-offline-replica的速度短暫標高，後又降低

這時咱們看一下，是否是手冊中說到的，region balance搶佔配額

果真，14點後，balance-region又有速度了，因此問題的關鍵已經找到了。

3、關鍵性參數

關閉調度
» config set replica-schedule-limit 64
Success!
» config set region-schedule-limit 0
Success!

咱們目前的場景是，balance期間，如何儘快的下線目標機器，region分佈在剩餘的機器中是否均衡不是咱們的首要任務，所以，咱們關閉region-schedule在剩餘機器中的balance，儘量大的開啓控制下線調度限制的參數replica-schedule-limit。就可以實現讓指定的機器儘量快的遷移走region來完成下線。

上圖可以看出，當咱們將region-schedule-limit配置爲0禁用region調度時，balance-region的值降值0 opm

此時，下線速度得到了大幅度的提高：

那麼同理，若是咱們臨時也禁止leader的調度，理論上調度器io將所有交給replica-schedule-limit
所以咱們執行以下命令：

» config set leader-schedule-limit 0
Success!

這是能看到待下線的機器balance速度又再次得到進一步的提高

4、效果對比

咱們把時間線拉長，與最開始未進行任何優化前的下線調度速度進行對比，能夠發現提高的很是明顯：

驗證結果
文檔這裏其實也是有問題的，當變成tombstone後，pd-ctl store命令是看不到tombstone節點的,除非你記得id

[tidb21 ~]$ /data1/tidb-ansible-3.0.5/resources/bin/pd-ctl -i -u http://192.168.1.248:2379  ? store 12131001
{
  "store": {
    "id": 12131001,
    "address": "192.168.1.249:20160",
    "state": 2,
    "version": "3.0.5",
    "state_name": "Tombstone"
  },
  "status": {
    "capacity": "5.904TiB",
    "available": "5.902TiB",
    "leader_weight": 1,
    "region_weight": 1,
    "start_ts": "2020-08-25T10:59:57+08:00",
    "last_heartbeat_ts": "2020-08-28T10:49:55.144024892+08:00",
    "uptime": "71h49m58.144024892s"
  }
}

或者使用api
curl pd-addr:port/pd/api/v1/stores?state=2

固然，監控也是能看到結果的

5、相關知識點

offline到tombstone這個過程自己是比較緩慢的，由於下線遷移的scheduler要和region balance scheduler搶佔資源
縮容是指預備將某個 Store 下線，經過命令將該 Store 標記爲 「Offline「 狀態，此時 PD 經過調度將待下線節點上的 Region 遷移至其餘節點。
故障恢復是指當有 Store 發生故障且沒法恢復時，有 Peer 分佈在對應 Store 上的 Region 會產生缺乏副本的情況，此時 PD 須要在其餘節點上爲這些 Region 補副本。
這兩種狀況的處理過程基本上是同樣的。replicaChecker檢查到 Region 存在異常狀態的 Peer後，生成調度在健康的 Store 上建立新副本替換異常的副本。
系統中同時運行有其餘的調度任務產生競爭，致使 balance 速度上不去。這種狀況下若是 balance 調度的優先級更高，能夠先停掉其餘的調度或者限制其餘調度的速度。例如 Region 沒均衡的狀況下作下線節點操做，下線的調度與 Region Balance 會搶佔 region-schedule-limit 配額，此時你能夠調小 replica-schedule-limit 以限制下線調度的速度，或者設置 disable-replace-offline-replica = true 來暫時關閉下線流程。

5、後續操做

後面的操做就很常規了
中止節點
[sync360@tidb21 tidb-ansible-3.0.5]$ ansible-playbook stop.yml -l xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx

編輯inventory.ini
註釋相關節點
重啓監控
ansible-playbook rolling_update_monitor.yml --tags=prometheus
其實重啓監控也同樣能看到節點仍是處於tombstone狀態，這塊也須要人爲的去pd-ctl裏刪除，手冊也寫得不全，尤爲是咱們這個案例，是要重啓後再加回集羣的，不刪除再加回來確定後續信息會有異常
stores remove-tombstone

Tips:遷移完成後，不要忘記調回region-balance-limit和leader-balance-limit

調回參數後，各節點開始balance，直到評分一致

6、思考

本案例咱們經過優化參數，達到大幅度提高下線調度速度，本案例是新加入集羣的機器正在調度，且執行了store delete操做後的優化思路，但其實還有更優解：

臨時下線維護操做：
主要利用tidb裏只有leader提供服務
遷出leader比遷移region快不少，同時調整downtime閾值，避免region遷移，就能夠快速下線維護,不過也要注意風險點，尤爲是寫入特色是很是分散的業務，具體的看原文，本文不在贅述
文章連接：
https://asktug.com/t/topic/33169