記一次HDFS的block corrupt事件
阿新 • • 發佈：2018-02-14
查找 保存 需要 一次 ilo maps 易懂 data edit
讓datanode重新去report一下唄，用這個命令：hdfs dfsadmin [-triggerBlockReport [-incremental] <datanode_host:ipc_port>]
如：hdf dfsadmin datanode1:50020 加-incremental這個參數就是增量report，不加就是全量report
我們執行了這個命令，不過corrupt block的數量仍然沒有減少，所以不是這個原因。
最終少華發現，我們datanode上配的dfs.datanode.data.dir這個參數中,/data1這個目錄沒了，估計是被誤操作刪掉了，導致datanode根本不回去/data1下去感知塊文件，所以導致出現了這個問題。
這個事件後，我發現，有時候逆向的去找問題找不出來，可以試試正向去找找，專治這類問題
不過這次解決問題的過程中真的學習了很多hdfs的內部機制。
格式有點亂，後面修改一下，晚上回家過年了。
還有最後兩天班，明天晚上回家過年了，可是CDH突然報了一個block missing的錯誤，用 hdfs fsck /檢查了一下，我們的塊一共有500W個，missing了將近100W個，天吶，不過由於Hdfs的replication的機制，只要不是3份全丟就可以修復，這樣，絕大部分的塊都修復了，但是還是有3000多個塊是3份都丟失了，3份全丟後，狀態就為corrupt，直接導致小時報和日報收到影響，很多用戶hive和impala查詢直接報錯了。
我和少華還有兆國趕緊去查找原因，先看了下CDH上關於HDFS的告警信息，發現有個failover controller的告警，you去看了下丟失了塊，發現塊文件仍然在盤上沒有丟，但是namenode已經無法感知到塊的存在了，不知道什麽原因。
我們先根據hdfs fsck / 的結果看了下corupt block所在的文件，發現大部分文件是小於128M的，由於我們的block大小設置為128M，所以小於128M的文件都只占用一個塊，block文件和源文件是一樣的，減小用戶受到的影響，我們先把那些丟失塊的文件在hdfs上面move到另一個目錄，然後記錄下文件的所有信息，包括：（權限列表，owner,group等）。然後用腳本把小於128M的文件的塊拷貝一份改成原來文件的名稱重新put上去，然後用split命令去多進程的批量進行chown和chmod，（少華腳本玩的確實6，對上面文本處理時的，sed,awk這些命令每部都很繁瑣，又加上循環，用的不熟很容易就出錯，高危操作啊。。。）之後用戶再去用到這部分數據的時候已經正常了。
因為我們僅僅是把這些文件MOVE走了，所以fsck還是會檢測corrupt block，不要緊的，此時檢測到文件的路徑已經是我們move後的路徑了。後面還剩下大於128M的文件沒有去修復，這個有點麻煩了，這些文件在磁盤中已經被分割為多個塊了，如果要修復的話，需要把這些塊文件手動拼接為一個文件重新上傳，我們隨便看了下其余的文件中的一個，將近100個G，七八百個塊，N個文件，還是很麻煩的。
於是我們又重新去找原因，先說下相關的原理：
重點來了：現在把這個步驟細化一下：
1.datanode首先去dfs.datanode.data.dir這個參數配置的目錄們下去尋找塊，正常情況下每個目錄裏面會有N個塊文件，還會有每個塊對應的meta文件， 如：blk_1141150594和blk_1141150594_67410808.meta
2.DATANODE會根據找到的這個meta文件去記錄對應block的信息並向namenode去匯報
3.收到datanode的匯報以後，namenode把信息記錄在blocksmap裏面NameNode作為HDFS中文件目錄和文件分配的管理者，它保存的最重要信息，就是下面兩個映射：
文件名=>數據塊
數據塊=>DataNode列表
其中，文件名=>數據塊保存在磁盤上（持久化）；但NameNode上不保存數據塊=>DataNode列表，該列表是通過DataNode上報建立起來的。
參考blockmaps的介紹：http://www.cnblogs.com/ggjucheng/archive/2013/02/04/2889386.html （簡單易懂）
晚上看到一篇博文，也是同樣的錯誤，他是剛好觸發了NAMENODE的雙活切換，然後出現這個問題。
Datanode增量匯報該block-datanode給 namenode（切換後的active namenode）的時候，edit log還沒從JournalNode同步過來，這時在namenode中已經有了block-datanode的映射（從剛才datanode的report中來），但是還沒有block-file（從edits文件裏面來）的映射，導致namenode認為這個塊不屬於任何文件，定義為該塊為invalidate block。這個在後臺日誌可以查到（後臺standby沒有完全變成activenamenode之前，會出現包含 invalidate block 的後臺日誌。）
讓datanode重新去report一下唄，用這個命令：hdfs dfsadmin [-triggerBlockReport [-incremental] <datanode_host:ipc_port>]
如：hdf dfsadmin datanode1:50020 加-incremental這個參數就是增量report，不加就是全量report
我們執行了這個命令，不過corrupt block的數量仍然沒有減少，所以不是這個原因。
最終少華發現，我們datanode上配的dfs.datanode.data.dir這個參數中,/data1這個目錄沒了，估計是被誤操作刪掉了，導致datanode根本不回去/data1下去感知塊文件，所以導致出現了這個問題。
這個事件後，我發現，有時候逆向的去找問題找不出來，可以試試正向去找找，專治這類問題
不過這次解決問題的過程中真的學習了很多hdfs的內部機制。
格式有點亂，後面修改一下，晚上回家過年了。
記一次HDFS的block corrupt事件