由于namenode和datanode的bug导致hdfs replication block不正常

hadoop集群使用的时间长了，或者datnaode， dfs一次运行的时间长了，会发现有很多的的， 在under 的 情况下，很长时间内仍然无法得到复制，始终处于under replication的状态，导致如果时间一长，磁盘损坏多的情况下，dfs中的就有丢失的风险，严重的时候就会丢失数据。
      从apache的hadoop JIRA上搜索类似的情形，发现了两个issue在这个问题，分别是：

 

仔 细看了下这两个patch：

• 端 启DataTransfer Daemon线程的时候是根据transferBlocks()里blocks数组的数量来启的，导致当某些block的replication为1，需 要transfer为2的时候，就会启两个DataTransfer进程，而这个进程里会对全局的xmitsInProgress进行++和--，一旦两 个线程都进行++，就会让xmitsInProgress变成2，这个信息会随着datanode的heartbeat传送到namenode端，而同时 由于namenode端同样也存在bug，在handleHeartbeat（）的时候，是根据maxReplicationStreams - xmitsInProgress来进行getReplicationCommand，maxReplicationStreams为2个，也就是如果此时 datnaode传过来的xmitsInProgress是2，那么namenode就会传会一个空的replication命令，导致datanode 端无法进行replication操作。
• namenode端的getReplicationCommand调用了BlockQueue 的poll（）方法，在这个方法里patch- 5479将namenode发送空replication指令的bug去除了。

当然，这个问题也可以通过重启datanode，让 datanode里的很多线程重新启动来解决，但是不断的重启datanode始终不是好的办法，加上代码的bug fix，才能根本上解决问题。