Hadoop 磁盤不足引起的一次「血案」

筆者的hadoop在不間斷的寫文件的過程當中報了以下錯誤

經查看發現是hadoop所在服務器的磁盤空間不足致使的。


好了，知道問題後筆者須要配置相關參數來避免該問題

一、與mapred.local.dir相關的參數
* mapred.local.dir.minspacestart：在mapreduce運行任務以前，檢查temporary 目錄下是否還有該選項配置的空閒空間，若是少於該配置，則map或reduce task不會分配到該TaskTracker上，以免因爲磁盤空間不足致使的task失敗。默認設置爲0，disable該功能
* mapred.local.dir.minspacekill：若是該磁盤卷下剩餘的磁盤空間不足該配置，則將正在運行的Task 殺掉。默認爲0，diabled該功能
另，若是服務器有多個塊設備最好將mapred.local.dir設置成多個目錄，每一個目錄對應一個塊設備，這樣多個task在同一個TaskTracker上運行的時候，就能夠分別寫不一樣的磁盤寫入點，以增大做業運行的磁盤吞吐率。
二、與dfs.data.dir相關的參數
* dfs.datanode.du.reserved：dfs寫文件塊時，若是當前datanode上的dfs.data.dir下剩餘磁盤空間不足該選項配置的空間大小，就不往該datanode繼續寫數據塊
* dfs.datanode.du.pct：同dfs.datanode.du.reserved，不過配置值爲一個百分比
最好預留些空間，避免寫文件失敗。

三、建議配額
mapred.local.dir.minspacestart = slots * dfs.block.size
mapred.local.dir.minspacekill = slots/2 * dfs.block.size
dfs.datanode.du.reserved = dfs.block.size * dfs.replication #最少留這麼多吧，建議留大些。

根據需求，筆者在hdfs-site.xml中配置了

<property>
    <name>dfs.datanode.du.reserved</name>
    <value>209715200</value>
</property>

而後重啓hadoop。可是！！！在這個時候筆者幹了件很是愚蠢的事情，format了namenode！ 是的就是這麼任性的格式化了。。。
這致使tmp/hadoop-root/dfs/name生成了新的clusterID，同時format後的啓動hadoop常常會包以下錯誤（hadoop-root-datanode-dongsys-hadoop.log）： 這事由於format格式化的時候會在name下生成新的clusterID，而不會改變data下的clusterID，name和data下的clusterID不一致致使。這時候咱們將修改data的clusterID同name的clusterID一致，而後重啓hadoop便可。

===================================================================

在裏，筆者要曾經嘗試，「恢復」格式化的數據。實際上format只是生成新的clusterID和blockpoolID。這裏筆者將name和data中涉及到的blockpoolID以及namespaceID都修改爲所需恢復的對呀data目錄下VERSION的數據。
好比筆者格式化前的datanode是BP-19792352-192.168.1.118-1422543381350。那麼BP-19792352-192.168.1.118-1422543381350/current/VERSION裏的信息是
namespaceID=846434132
cTime=0
blockpoolID=BP-19792352-192.168.1.118-1422543381350
layoutVersion=-56

將name/current/VERSION的namespaceID、blockpoolID都修改爲和上面的信息一致，而後重啓hadoop，結果Configured Capacity、DFS Used、Non DFS Used等信息都正確了，可是實際上因此的datanode下文件都是沒法正常讀取到的。
這裏筆者還不知道是爲何，但願有知曉的朋友告知下，筆者也會繼續學習hadoop需找答案。

參考資料：
http://www.linuxidc.com/Linux/2012-11/74478.htm