Doris 一個 tablet 有多個副本，可能因為某些情況導(dǎo)致狀態(tài)不一致。Doris 會嘗試自動修復(fù)這些狀態(tài)不一致的副本，讓集群盡快從錯誤狀態(tài)中恢復(fù)。每個副本的狀態(tài)有以下幾種
- BAD : 即副本損壞。包括但不限于磁盤故障、BUG等引起的副本不可恢復(fù)的損毀狀態(tài)
- VERSION_MISSING : 版本缺失。Doris 中每一批次導(dǎo)入都對應(yīng)一個數(shù)據(jù)版本。而一個副本的數(shù)據(jù)由多個連續(xù)的版本組成。而由于導(dǎo)入錯誤、延遲等原因，可能導(dǎo)致某些副本的數(shù)據(jù)版本不完整
- HEALTHY : 健康副本。即數(shù)據(jù)正常的副本，并且副本所在的 BE 節(jié)點狀態(tài)正常
Tablet 的狀態(tài)是有所有副本狀態(tài)來決定的，狀態(tài)如下：
- REPLICA_MISSING：副本缺失（即存活副本數(shù)小于期望副本數(shù)）
- VERSION_INCOMPLETE：存活副本數(shù)大于等于期望副本數(shù)，但其中健康副本數(shù)小于期望副本數(shù)。
- REPLICA_RELOCATING ：擁有等于 replication num 的版本完整的存活副本數(shù)，但是部分副本所在的 BE 節(jié)點處于 unavailable 狀態(tài)
- REPLICA_MISSING_IN_CLUSTER ： 當(dāng)使用多 cluster 方式時，健康副本數(shù)大于等于期望副本數(shù)，但在對應(yīng) cluster 內(nèi)的副本數(shù)小于期望副本數(shù)
- REDUNDANT：副本冗余
- COLOCATE_MISMATCH：針對 Colocation 屬性的表的分片狀態(tài)。表示分片副本與 Colocation Group 的指定的分布不一致
- COLOCATE_REDUNDANT：針對 Colocation 屬性的表的分片狀態(tài)。表示 Colocation 表的分片副本冗余。
- FORCE_REDUNDANT：這是一個特殊狀態(tài)。只會出現(xiàn)在當(dāng)期望副本數(shù)大于等于可用節(jié)點數(shù)時，并且 Tablet 處于副本缺失狀態(tài)時出現(xiàn)。這種情況下，需要先刪除一個副本，以保證有可用節(jié)點用于創(chuàng)建新副本
- HEALTHY：健康分片，即條件[1-8]都不滿足。
下面這張圖是 Doris 副本檢查及副本恢復(fù)的整體流程圖
名詞解釋：
TabletChecker（TC）：TabletChecker 作為常駐的后臺進(jìn)程，會定期檢查所有分片的狀態(tài)。對于非健康狀態(tài)的分片，將會交給 TabletScheduler 進(jìn)行調(diào)度和修復(fù)。修復(fù)的實際操作，都由 BE 上的 clone 任務(wù)完成。FE 只負(fù)責(zé)生成這些 clone 任務(wù)。
TabletScheduler 每5秒進(jìn)行一次調(diào)度
TabletScheduler 每次調(diào)度最多 50 個 tablet
最大等待調(diào)度任務(wù)數(shù)和運行中任務(wù)數(shù)為 2000。當(dāng)超過 2000 后，TabletChecker 將不再產(chǎn)生新的調(diào)度任務(wù)給 TabletScheduler。
最大均衡任務(wù)數(shù)為 500。當(dāng)超過 500 后，將不再產(chǎn)生新的均衡任務(wù)
每塊磁盤用于均衡任務(wù)的 slot 數(shù)目為2。這個 slot 獨立于用于副本修復(fù)的 slot
一個 clone 任務(wù)超時時間范圍是 3min ~ 2hour。具體超時時間通過 tablet 的大小計算。計算公式為 (tablet size) / (5MB/s)。當(dāng)一個 clone 任務(wù)運行失敗 3 次后，該任務(wù)將終止。
TabletScheduler（TS）：是一個常駐的后臺線程，用于處理由 TabletChecker 發(fā)來的需要修復(fù)的 Tablet。同時也會進(jìn)行集群副本均衡的工作。
副本恢復(fù)流程
首先是 FE 的 tablet 檢查進(jìn)程，會定期的對所有分片進(jìn)行檢查，然后會不健康的分片，交給Tablet調(diào)度進(jìn)程去完成調(diào)度和修復(fù)，下面我們主要介紹一下 FE 這邊怎么生成調(diào)度及BE怎么完成Clone 和修復(fù)。
首先我們要找到一個目標(biāo)BE，可以用來Clone 一個新的副本
找到一個可用的 BE 及副本存放路徑，作為我們副本Clone的目標(biāo)節(jié)點
首先這個 BE 是要 Alive 的
應(yīng)該將現(xiàn)有副本的 BE 節(jié)點排除在外，因為同一個 BE 只能有一個副本。
選擇一個 proper tag BE
- 在副本丟失的情況下，我們要選擇一個有副本丟失的 tag
- 根據(jù)副本分步情況，如果沒有 副本丟失 tag 的，這種應(yīng)該拋出異常
- 為了刪除多余的副本，這時候需要找出一個多余副本的標(biāo)簽
這個目標(biāo) BE 要有可以使用執(zhí)行 Clone 任務(wù)的 Solt
找到一個可以用來 Clone 副本的合適的路徑，這里要考慮磁盤容量和使用百分比
目標(biāo)是要找到一個負(fù)載（ClusterLoadStatistics（CLS））相對低的路徑，這里TabletScheduler 會每隔 20s 更新一次 CLS
找到一個適合的副本源
這個副本應(yīng)該是健康的
源副本所在的BE有可用的Clone solt
向目標(biāo) BE 發(fā)送克隆任務(wù)
目標(biāo) BE 提交 Clone task 任務(wù)
判斷 tablet 副本都否存在，如果不存在開始 Clone 一個新的 tablet
向源 BE 發(fā)送一個創(chuàng)建Snapshot的請求，這里源 BE 之所以要創(chuàng)建Snapshot，是因為方式在 clone 修復(fù)的時候，這個時候有數(shù)據(jù)寫導(dǎo)致Clone 失敗，通過創(chuàng)建快照來避免這個問題。
源 BE 檢查 tablet 狀態(tài)及版本等是否正常
如果源 BE 的tablet 副本狀態(tài)、版本等都是正常的，執(zhí)行創(chuàng)建Snapshot，并返回
目標(biāo) BE 從源 BE 下載剛才創(chuàng)建的Snapshot到本地，完成副本恢復(fù)
實例
用戶的操作步驟：
1. 修改已有表字段長度， varchar(60) --> varchar(90) 2. tablet出現(xiàn)損壞 3. 自動修復(fù)失敗。
下面我們來看一個實例，怎么去定位 Tablet 副本均衡失敗的原因
- 首先我們要通過
show tablet tablet_id查看這個 tablet 副本的情況 - 在執(zhí)行上面命令返回的數(shù)據(jù)最后一列的命令
類似下面的命令
SHOW PROC'/dbs/10005/17679/partitions/774669/6061262/6061295';
然后我們可以看到最下面的一行，顯示這個副本正Clone，但是過了一會并沒有Clone 成功，這個時候我們可能感覺無從下手，不知道為什么了，我們這個時候要去關(guān)注 cluster_balance, 通過這個查看副本均衡調(diào)度任務(wù)執(zhí)行的情況
- 查看副本調(diào)度的任務(wù)情況，執(zhí)行下面的命令
SHOW PROC '/cluster_balance/pending_tablets'; 或者 SHOW PROC '/cluster_balance/running_tablets';
在返回的結(jié)果里我們可以看到：SrcBe 和 DestBe
這個時候我們就要去目標(biāo)BE上去查看日志，在日志里搜索這個 Tablet Id，然后我在日志里看到下面的信息
[圖片上傳失敗...(image-d42cdf-1662968106713)]
顯示這個目標(biāo) BE 在去源 BE 請求創(chuàng)建 tablet 副本快照的時候失敗了，這個時候我懷疑可能是其他的副本也是有問題的，正常情況下這個地方不應(yīng)該失敗，我通過
SHOW PROC'/dbs/10005/17679/partitions/774669/6061262/6061299';
注意：
這里因為當(dāng)時是在查看三個 tablet的問題，所有這個tablet id 前后對不上，都是一樣的問題
我去看剛才 Clone 失敗的副本均衡任務(wù)的源 BE 上副本對應(yīng)的的哪行數(shù)據(jù)最后一列：CompactionStatus ，然后將這個URL在瀏覽器里訪問，看一下是不是剛才猜測的這個副本也存在問題。
然后看到了下面的信息，版本丟失了
因為有三副本，之前只損壞一個副本，是不是另外一個副本也是這種情況呢，我又去看了另外一個be上的副本狀態(tài)，最后發(fā)現(xiàn)也是同樣的問題
最后去看了一下，源 BE 上的日志，搜索了 3341 這個版本號，來確認(rèn)是否真版本丟失了
通過上面的日志，確認(rèn)了這個tablet 三個副本都是損壞的，而且沒辦法修復(fù)
這種情況下，我們就要通過 BE 日志來分析具體的原因，是因為操作不當(dāng)還是程序存在 Bug，如果是操作不當(dāng)，可以先從操作上規(guī)避，然后將這個問題提交給社區(qū)，有社區(qū)開發(fā)人員定位分析，然后修復(fù)
針對這個里面沒辦法修復(fù)的，只能先刪除這個分區(qū)，重新將這個分區(qū)的數(shù)據(jù)導(dǎo)入進(jìn)來
正常情況下Doris不會出現(xiàn)某個tablet 副本全部損壞不可修復(fù)的問題，
現(xiàn)在Doris 社區(qū)發(fā)版速度很快，而且在1.1.x版本上維護(hù)了一個準(zhǔn)LTS版本，所以建議大家及時升級到最新版本，正常按照社區(qū)的升級手冊，不會出現(xiàn)數(shù)據(jù)丟失的情況
因為Doris 不支持高版本超低版回退，大家可能比較擔(dān)心我一旦升級錯誤怎么辦，下一篇文章我來給大家講解怎么進(jìn)行升級前的備份，在升級失敗后，可以回退到之前的版本，正常運行。
