問題
在Doris 0.13.15 預編譯版本中
Doris decommission三個 be節點卡住
alter system decommission backend "be_host-1:9050"
alter system decommission backend "be_host-2:9050"
alter system decommission backend "be_host-3:9050"
卡住
分析
查看原始碼，需要調整catalog_trash_expire_second引數
其余引數可以查看《Doris FE配置中文描述》
這個引數的意義在于提供了一個保護機制，洗掉資料庫（表/磁區）后，可以在這個catalog_trash_expire_second時間內使用 RECOVER stmt 恢復它，
此引數指定了最大資料保留時間， 一段時間后，資料將被永久洗掉
這個是保護用的，怕有人洗掉了資料后悔來不及恢復資料
所以
因為有人洗掉了表的原因，導致由于一些表的磁區被洗掉了，但是還在回收區導致的be decommission卡死
原始碼分析
erasePartition()方法中的isExpire()里就是通過這個引數進行判斷是否可以洗掉磁區，當然他必須大于一個最小的洗掉延遲時間minEraseLatency（10min）
解決
將引數
catalog_trash_expire_second（默認值86400，1天）
設定小點，等待待回收的磁區資料過期后，decommission即可完畢
后續問題
將引數調整小后，下線的三個節點中，有2個已經下線成功，但是還有一個be節點卡在了剩余tablet 為2個的狀態
解決辦法
CANCEL DECOMMISSION BACKEND "be_host-1:9050";
等待show proc ‘/statistic’;中不健康的tablet降為0后再次下線，當然你也可以嘗試 不用等待不健康tablet降為0后執行執行下線命令
alter system decommission backend "be_host-1:9050"
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/289642.html
標籤：其他