CannotObtainBlockLengthException问题分析

用户反馈MR任务失败，通过查看job的diagnose信息，发现如下异常

另外需要交待一下背景，下午发生2个datanode机器同时宕机的问题，我们是有2副本的数据的，因此当2个datanode同时失效，一定会有一定比例的块丢失，在这两个datanode恢复一个之前，一定又有hdfs的客户端报错Missing Block。

本文这个问题更加特殊，在这个任务失败前，2个宕机节点都已经恢复了，不存在missing block。

所以这个情况给了我们一个非常重要的警示，即使不存在missing block，不代表hdfs的数据状态就100%正常的，而且hdfs不会给出提示，目前只有客户端读取这些数据的时候才能发现，不可不谓一个重大的隐患。

 

在datanode恢复以后，没有missing block依然有状态不正常的数据，我们可以很自然的想到，数据没有丢，但是正在write过程中的数据，由于datanode强行的关闭，导致namenode对block的状态了解的不正常。

涉及到write的过程，我们很自然的可以了解到写锁，在hdfs里叫租约机制。 这个时候我们的一个猜想就是这个block是存在的，但是因为datanode的非正常关闭导致namenode对于这个block的认知依然是它还在openforwrite状态。

我们知道Hadoop提供了关于租约机制的修复工具，如下

hdfs debug recoverLease -path [path]  需要指定文件路径。

文件路径怎么来？

通过异常日志，我们可以看到blk_XXXXXXXX  这个就是blockId

通过 hdfs fsck -showprogress -blockId blk_XXXXXXX 我们可以了解到这个block对应的目录是什么