為(wei)了幫助企(qi)業更好(hao)(hao)地(di)進(jin)行(xing)大數據處理，我們在(zai)此(ci)前 TDengine 3.x 系列版本中進(jin)行(xing)了幾項(xiang)與集群相關的(de)優(you)化和(he)(he)新(xin)功(gong)能(neng)開發，以(yi)提升集群的(de)穩定性和(he)(he)在(zai)異(yi)常(chang)情況(kuang)下的(de)恢(hui)復能(neng)力。這(zhe)些優(you)化包括 clusterID 隔離、leader rebalance、raft learner 和(he)(he) restore dnode。本文將(jiang)對這(zhe)幾項(xiang)重要優(you)化進(jin)行(xing)詳(xiang)細闡(chan)述，以(yi)解(jie)答企(qi)業在(zai)此(ci)領域的(de)疑(yi)問，并幫助大家更好(hao)(hao)地(di)應對相關挑戰。
clusterID 隔離
- 問題
- firstEp 節點掛掉后，磁盤掛載錯誤，掛載了一個空白磁盤啟動，或者 firstEp 數據被意外刪除；
- firstEp 再次重啟。嚴重點是這個出錯的節點，導致其他節點也無法工作，整個集群都掛掉，集群失去了高可用特性。
- 造成的后果
firstEp 節點在無數據的情況下重新啟動，相當于新創建了一個集群，它重新初始化為一個新集群（重新生成了 clusterid），但此時原集群（舊的 clusterId）中的其它 N-1 個節點仍然向它們所保存的 firstEp 發送心跳，而收到心跳消息的 firstEp 已經是一個新的集群了，所以會拒絕心跳消息，返回節點不存在，要求心跳發送方下線，這些節點收到下線通知后會主動下線，直接導致原集群中的所有節點都不可用。
- 解決辦法
為(wei)節(jie)(jie)點(dian)(dian)心跳、raft 心跳增(zeng)加對(dui) clusterid 的(de)判斷，即對(dui) clusterid 進行隔離，讓具有不同 clusterid 的(de)節(jie)(jie)點(dian)(dian)可以獨立運行。這(zhe)種解(jie)決辦法可以應對(dui)節(jie)(jie)點(dian)(dian)已(yi)經在空白數(shu)據上重啟的(de)情(qing)況。
- 解決后的效果
在出(chu)現磁盤故障后，firstEp 節(jie)點啟動后，會形成(cheng)兩個(ge)(ge)集(ji)群(qun)，一(yi)個(ge)(ge)是 firstEp 節(jie)點形成(cheng)的(de)單節(jie)點新集(ji)群(qun)，另一(yi)個(ge)(ge)是所有其他節(jie)點保(bao)持舊 clusterid 的(de)舊集(ji)群(qun)。兩個(ge)(ge)集(ji)群(qun)可以獨(du)立且互不干擾的(de)正常運行。
RAFT Leader Rebalance（TDengine Enterprise 企業版）
- 問題
比較常見的使用場景，在滾動升級后，所有的 leader 都被趕到一個節點上，整個集群嚴重失衡。
- 解決辦法
增加 balance vgroup leader; 的 SQL 命(ming)令，由 DBA 人工觸發集群再平衡，該(gai)命(ming)令會依次(ci)順序對每個(ge) vgroup 強制(zhi)重新(xin)選(xuan)舉(ju) RAFT leader。因為選(xuan)舉(ju)是隨機的，所以(yi)我們可以(yi)通過選(xuan)舉(ju)讓 leader 遷(qian)移到其他的節點(dian)上。
- 解決后的效果
選(xuan)(xuan)舉(ju)理論(lun)上(shang)(shang)隨機選(xuan)(xuan)出 leader，導(dao)致(zhi) leader 散開的結果。理論(lun)上(shang)(shang)會均勻，實(shi)際上(shang)(shang)不會絕對(dui)均勻。
Raft Learner
- 問題
在副本變更時（create mnode, alter db replia），如果存量數據（元數據或時序數據）量比較大時，相應操作會執行很長時間，要等待存量數據同步完成后命令才能執行完成，并且在此期間會阻塞數據寫入。
- 解決辦法
在 Leader/Follower/Candidate 之外引入第四種 Raft 角色——Raft learner。Raft Learner 只同步數據不參與選主，也不參與數據寫入時的一致性協議。當 Raft Learner 的數據同步進度被追上后才會變身為 Follower，成為 Raft 集群的一部分。這樣命令雖然執行很長時間，但不會阻塞寫入。
- 受影響的命令
Create mnode on dnode id;
ALTER DATABASE power replica 3;- 解決后的效果
副本變更時(shi)，不會再(zai)阻(zu)塞寫入。相應的命令執(zhi)行可以很快返回。
Restore dnode（TDengine Enterprise 企業版）
- 問題
數據盤出現問題，重新掛載新數據盤，這個節點上所有數據目錄都丟失。
- 解決辦法
增加命令：
restore dnode <dnode_id>；# 恢復dnode上的mnode，所有vnode和qnode
restore mnode on dnode <dnode_id>；# 恢復dnode上的mnode
restore vnode on dnode <dnode_id> ；# 恢復dnode上的所有vnode
restore qnode on dnode <dnode_id>；# 恢復dnode上的qnode該命令，從 mnode 讀取節點(dian)中關于 mndoe、vnode、qnode 的信息，按照這些在節點(dian)重(zhong)建 mnode、vnode、qnode，在重(zhong)建結束后，會(hui)開始從其(qi)他副本復制數據。
- 解決后的效果
按(an)照原(yuan)有的 taos.cfg 的配置啟動 taosd，該節(jie)點會(hui)自動加(jia)入群(qun)，并(bing)且 dnode 顯示為 ready，即(ji) online 狀(zhuang)態。在節(jie)點變為 online 后，通(tong)過命令可恢復全(quan)部(bu) mnode、vnode、qnode，也可以分別(bie)恢復。
- 功能限制
該(gai)功能是(shi)基于已有(you)的(de)復(fu)制功能的(de)恢復(fu)，不是(shi)災難恢復(fu)或(huo)者(zhe)備份恢復(fu)，所以(yi)對于 mnode 和(he)(he) vnode 來(lai)說，使用該(gai)命(ming)令一定(ding)是(shi)還存(cun)在其他 mnode 和(he)(he) vnode 的(de)其他副本(ben)。該(gai)命(ming)令不能修(xiu)復(fu)數(shu)據目錄中個別(bie)文件的(de)損壞(huai)或(huo)者(zhe)丟失，是(shi)整體(ti)的(de)恢復(fu)一個 mnode 或(huo)者(zhe) vnode。
寫在最后
通過本文，相信大家已經初步了解了上述幾項功能優化。如果你對這些功能有進一步的了解需求，或者希望進一步討論在應用中遇到的問題，歡迎添加小T vx：tdengine，與我們專業的解決方案(an)架構師直接溝通。
