hadoop异常：Be Replicated to 0 nodes, instead of 1

Hadoop 坑爹的Be Replicated to 0 nodes, instead of 1 异常

博客分类：
• Java 编程

HadoopITeyeJSP算法Apache 

有段时间不写博客了，感觉自己懒惰了不少，当然也是不够努力。近一年的时间一直在开发Hadoop基础应用。 



  新的项目上线之后发现，有些会员上传资源到我们集群的速度，既然跟我们集群的吞吐量差不多，达到了70M+/s的速度。 在向集群put数据时，抛出了异常：

1. nodes, instead of 1

这样的信息告诉我，集群内部无可用的节点了，因为是在put阶段出现的，直觉告诉我，所有的节点是不是都已经写满数据了？ 



节点少的情况比较容易观察Hadoop的一些问题，查看dfshealth.jsp页面发现，至少有三台节点可写，但dfsClient put数据仍然抛出无节点可用的异常。 



追究源码，NameNode身边的 ReplicationTargetChooser#isGoodTarget方法给出了说明：

1. // check the communication traffic of the target machine
2. if (considerLoad) {
3. ;
4. int size = clusterMap.getNumOfLeaves();
5. ) {
6. avgLoad = (double)fs.getTotalLoad()/size;
7. }
8. if (node.getXceiverCount() > (2.0 * avgLoad)) {
9. logr.debug("Node "+NodeBase.getPath(node)+
10. " is not chosen because the node is too busy");
11. return false;
12. }
13. }

isGoodTarget方法对预选的数据节点做出了终审判决，然而除了磁盘空间可利用外，另外需稳定在一定的压力之下，这里的标准是Datanode中XceiverServer所接受的连接数，我们在使用Hadoop时，这个值很容易被忽略，因为这个值不方便被统计到。上段代码说明当前节点的连接数，不得大于集群所有节点平均连接数的两倍。为了使我的系统尽量独力，我在dfshealth.jsp 页面把每台节点的连接数打印了出来，结果发现正好符合上述代码的判断。 



 



比如ReplicationTargetChooser选择了node13，那么即使node13有大片的空间可写，最终也会被上述代码认为是一个不符合条件的节点。

1. > ((27 + 45 + 44 + 54 + 35 + 50 + 104 + 55 + 73 + 69 + 157 + 146)/12 * 2)

这样的异常，一般解决办法是添加节点，或是在节点允许的情况下，对这段算法进行上调。