記一次HDFS的block corrupt事件

還有最后兩天班，明天晚上回家過年了，可是CDH突然報(bào)了一個(gè)block missing的錯(cuò)誤，用 hdfs fsck /檢查了一下，我們的塊一共有500W個(gè)，missing了將近100W個(gè)，天吶，不過由于Hdfs的replication的機(jī)制，只要不是3份全丟就可以修復(fù)，這樣，絕大部分的塊都修復(fù)了，但是還是有3000多個(gè)塊是3份都丟失了，3份全丟后，狀態(tài)就為corrupt，直接導(dǎo)致小時(shí)報(bào)和日?qǐng)?bào)收到影響，很多用戶hive和impala查詢直接報(bào)錯(cuò)了。
我趕緊去查找原因，先看了下CDH上關(guān)于HDFS的告警信息，發(fā)現(xiàn)有個(gè)failover controller的告警，you去看了下丟失了塊，發(fā)現(xiàn)塊文件仍然在盤上沒有丟，但是namenode已經(jīng)無法感知到塊的存在了，不知道什么原因。
我們先根據(jù)hdfs fsck / 的結(jié)果看了下corupt block所在的文件，發(fā)現(xiàn)大部分文件是小于128M的，由于我們的block大小設(shè)置為128M，所以小于128M的文件都只占用一個(gè)塊，block文件和源文件是一樣的，減小用戶受到的影響，我們先把那些丟失塊的文件在hdfs上面move到另一個(gè)目錄，然后記錄下文件的所有信息，包括：（權(quán)限列表，owner,group等）。然后用腳本把小于128M的文件的塊拷貝一份改成原來文件的名稱重新put上去，然后用split命令去多進(jìn)程的批量進(jìn)行chown和chmod，（對(duì)上面文本處理時(shí)的，sed,awk這些命令每部都很繁瑣，又加上循環(huán)，用的不熟很容易就出錯(cuò)，高危操作啊。。。）之后用戶再去用到這部分?jǐn)?shù)據(jù)的時(shí)候已經(jīng)正常了。
因?yàn)槲覀儍H僅是把這些文件MOVE走了，所以fsck還是會(huì)檢測corrupt block，不要緊的，此時(shí)檢測到文件的路徑已經(jīng)是我們move后的路徑了。后面還剩下大于128M的文件沒有去修復(fù)，這個(gè)有點(diǎn)麻煩了，這些文件在磁盤中已經(jīng)被分割為多個(gè)塊了，如果要修復(fù)的話，需要把這些塊文件手動(dòng)拼接為一個(gè)文件重新上傳，我們隨便看了下其余的文件中的一個(gè)，將近100個(gè)G，七八百個(gè)塊，N個(gè)文件，還是很麻煩的。
于是我們又重新去找原因，先說下相關(guān)的原理：
重點(diǎn)來了：現(xiàn)在把這個(gè)步驟細(xì)化一下：
1.datanode首先去dfs.datanode.data.dir這個(gè)參數(shù)配置的目錄們下去尋找塊，正常情況下每個(gè)目錄里面會(huì)有N個(gè)塊文件，還會(huì)有每個(gè)塊對(duì)應(yīng)的meta文件， 如：blk_1141150594和blk_1141150594_67410808.meta
2.DATANODE會(huì)根據(jù)找到的這個(gè)meta文件去記錄對(duì)應(yīng)block的信息并向namenode去匯報(bào)
3.收到datanode的匯報(bào)以后，namenode把信息記錄在blocksmap里面

NameNode作為HDFS中文件目錄和文件分配的管理者，它保存的最重要信息，就是下面兩個(gè)映射：

文件名=>數(shù)據(jù)塊

數(shù)據(jù)塊=>DataNode列表

其中，文件名=>數(shù)據(jù)塊保存在磁盤上（持久化）；但NameNode上不保存數(shù)據(jù)塊=>DataNode列表，該列表是通過DataNode上報(bào)建立起來的。
參考blockmaps的介紹：http://www.cnblogs.com/ggjucheng/archive/2013/02/04/2889386.html （簡單易懂）
晚上看到一篇博文，也是同樣的錯(cuò)誤，他是剛好觸發(fā)了NAMENODE的雙活切換，然后出現(xiàn)這個(gè)問題。
Datanode增量匯報(bào)該block-datanode給 namenode（切換后的active namenode）的時(shí)候，edit log還沒從JournalNode同步過來，這時(shí)在namenode中已經(jīng)有了block-datanode的映射（從剛才datanode的report中來），但是還沒有block-file（從edits文件里面來）的映射，導(dǎo)致namenode認(rèn)為這個(gè)塊不屬于任何文件，定義為該塊為invalidate block。這個(gè)在后臺(tái)日志可以查到（后臺(tái)standby沒有完全變成activenamenode之前，會(huì)出現(xiàn)包含 invalidate block 的后臺(tái)日志。）
這個(gè)是網(wǎng)上的哥們 遇到的問題，怎么驗(yàn)證我們也是這個(gè)問題呢？
讓datanode重新去report一下唄，用這個(gè)命令：hdfs dfsadmin [-triggerBlockReport [-incremental] <datanode_host:ipc_port>]
如：hdf dfsadmin datanode1:50020 加-incremental這個(gè)參數(shù)就是增量report，不加就是全量report
我們執(zhí)行了這個(gè)命令，不過corrupt block的數(shù)量仍然沒有減少，所以不是這個(gè)原因。
最終發(fā)現(xiàn)，我們datanode上配的dfs.datanode.data.dir這個(gè)參數(shù)中,/data1這個(gè)目錄沒了，估計(jì)是被誤操作刪掉了，導(dǎo)致datanode根本不會(huì)去/data1下去感知塊文件，所以導(dǎo)致出現(xiàn)了這個(gè)問題。
這個(gè)事件后，我發(fā)現(xiàn)，有時(shí)候反向的過程中忽略了一些步驟，導(dǎo)致無法查出問題專治這類問題，正向查一遍可能就查出了。
我們昨天忽略了一步，就是找出每一個(gè)塊文件的路徑、統(tǒng)計(jì)一下，如果做了的話看到都在/data1這個(gè)目錄下，肯定能發(fā)現(xiàn)問題所在
現(xiàn)在想想
不過這次解決問題的過程中真的學(xué)習(xí)了很多hdfs的內(nèi)部機(jī)制。
格式有點(diǎn)亂，后面修改一下，晚上回家過年了。