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