hdfs datanode decomission引發的block missing

最近在幫公司下線離線計算集羣的機器，逐臺decomiss，下到第四臺機器時，cdh告警來了，丟失塊大於集羣的1%，算了一下集羣有400多臺，下線一臺不應該告警，以爲下線步驟有問題，點了中止下線，後來看了下其實步驟是沒問題的，由於下線的機器配置比較好，所以確實這臺機器上存儲了集羣1%以上的block，於是終止了datanode的decomission，但是集羣還是出現了14個 missing block，按照常理，hdfs上的文件丟失副本只要不是所有副本全丟，過段時間hdfs都會把這些副本從其他節點copy一份，但是這些block隨着時間的增加永遠不會恢復。
確認了下線步驟沒有問題以後，選擇原來的datanode繼續decomission，但是這一步會一直卡住，不會完成，看了下datanode的日誌，確實是在移動數據，但是看節點的io很小，完全達不到正常下線節點時的io。於是這個節點先略過，下線其他節點，發現也出現同樣情況，看來繼續下線是不行了。
看了一下clouddera社區的一個issue，這好像是cdh的一個bug，上面cdh的官方人員說要把datanode刪掉再重新加回來就可以下線了。
於是我把datanode停了，通過cdh監控按到節點上的block全部複製完以後，直接把datanode刪除掉了， 沒有走正常decomission的流程。弄完之後去hdfs的監控看了下，這個節點直接沒了，也不會存在僵死的節點。那就不用再安裝回來重新decomission一遍了。用如此的方式，把下線節點的工作都完成之後。來好好查看一下這個問題。
丟塊的提示是在hdfs的ui看到的

既然有丟塊，那我們就用hdfs fsck /這個命令檢查一下，檢查的結果竟然沒有丟失塊，
於是用hdaoop dfsadmin -report 這個命令檢查了一下，提示說丟失了14個block，檢查的結果是和hdfs界面上的提示是相符的。
既然2個命令的結果不同，那就說明至少有一個是有問題的，所以2個命令都被假設有可能結果是不準確的。
後來通過了解還有一種可能就是文件在被寫入的過程中client異常掛掉了，導致租約沒有釋放，寫入沒有正常關閉，也有可能造成塊無法使用。
參考https://www.cnblogs.com/cssdongl/p/6700512.html
如果這種情況，可以通過hdfs debug recoverLease -path <path-of-the-file> -retries <retry times> 可以恢復文件租約。
但是我們只知道有block有問題，不知道這些塊屬於哪些文件，怎麼驗證我們的猜想呢
通過命令 hdfs fsck / -openforwrite |grep -i openforwrite |awk '{print $1}'，把當前正在寫入的文件找出來，寫個循環腳本，對裏面的文件進行恢復租約，
就可以對所有被正在寫入的文件去恢復租約，腳本運行完之後，果然這些block missing消失了。