整理整个hadoop2.4.1的decommission以及blockmanager对备份补充的全流程

因为公司是用的hadoop2.4，然后decommission有问题，为此过下整个处理流程。

 

1. DecommissionManager > check 定期检查，从blockmanager里面获取datanode，然后循环。

 

 

check-》

2. d.isDecommissionInProgress() 判断datanode是否为decommission状态，如果是，则检查：checkDecommissionState； 如果不是，那么就是正常的datanode，忽略

3. checkDecommissionState-》

再次判断datanode是否为decommission状态，如果不是，将返回decommission完成（这个返回结果用不上）。

如果是，调用blockManager的 isReplicationInProgress 方法判断datanode是否有节点在备份复制。

3.1 如果没有，那么就认为decommission完成了，随后调用node.setDecommissioned() 将节点状态设置为decommission完成。

从这里来看，判断decommission完成的条件是，首先它是decommission状态，接下来判断没有进行备份复制（或者说备份复制已经完成）， 这样就可以认为这个节点已经完成decommission了。

 

 

接下来，如果 3.1 判断结果是有，那么decommission尚未完成，判断下一个datanode。等到下一次DecommissionManager.check()的检查。

 

 

4.isReplicationInProgress-》

这里有三个概念：

 

underReplicatedBlocks  正在备份复制的block

decommissionOnlyReplicas 仅进行decommission的备份数

underReplicatedInOpenFiles 正在写的block，且该block不是最后的备份block，或者小于最小备份数的block数。

 

 

循环每个block，看下这个block有多少个备份。同时获取该block的默认备份数。判断是否需要replication，判断依据自然就是如果当前备份数少于默认备份数（或者没有足够的rack），就要进行replication。

这里要做个简单判断，如果这个block正在写，如果它是最后一个block且当前block的存活备份数大于最小备份数，那么就跳过。

否则，underReplicatedInOpenFiles+1. 就是说，只有正在写，而且还不是最后一个block或者说它小于最小备份数，underReplicatedInOpenFiles才加一。

 

 

logBlockReplicationInfo 只有如下情况才会打日志：

a 这个datanode第一次进行的isReplicationInProgress 确认（如果有多个block，那么只有第一个block才会打）。

 

 

 

 

status 作为最终结果状态判断， 默认为false（如果最终返回false，那么这个dn就不是replication状态了，只有这个dn的所有block都不是replication状态，才能认为这个dn不是replication状态）

status 一旦被置为true，那么就一直为true。如果status被置为false，那么有两种情况，就是它就是从第一个block判断到最后一个block判断都是false，或者说前存活的block备份数一直大于block的默认备份数；

 或者可能是前存活的block备份数小于block的默认备份数，但是当前存活block的备份大于全局默认备份数，那么status还是会置回false。

 

 

 

 

underReplicatedBlocks 增加：

只要前存活的block备份数小于block的默认备份数，