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

原文地址：http://dongyajun.iteye.com/blog/1039836

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

 org.apache.hadoop.ipc.RemoteException: java.io.IOException: File /xxx/xxx/xx could only be replicated to 0 nodes, instead of 1  

org.apache.hadoop.ipc.RemoteException: java.io.IOException: File /xxx/xxx/xx could only be replicated to 0 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.      double avgLoad = 0;  4.      int size = clusterMap.getNumOfLeaves();  5.      if (size != 0) {  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有大片的空间可写，最终也会被上述代码认为是一个不符合条件的节点。 

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

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

 

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