HDFS Append 设计文档的QA（Questions about the “Append

LiteHeaven

2012-09-08

本文是关于Append设计文档中一些设计点的QA，原文的地址已经不记得是从HDFS中的那个Jira上看到的了，可以参考Append设计文档来看：

https://issues.apache.org/jira/secure/attachment/12445209/appendDesign3.pdf

译文如下：

以下场景中，可能发生那些失败，以及如何处理？
1. Blocks being copied (replicated/balance)
  - 源DN启动replicating过程，过程中的错误可能导致过程不会完成。目标DN首先将数据写入"blocksBeingReplcated"文件夹，如有错误发生，目标DN将这些残缺的block移除，当这个DN重启时，会将所有的"blocksBeingReplcated"中的blk移除。
2. Blocks being written, no sync, no append
3. Blocks being written, syncs, no append
4. Blocks being appended, no sync
5. Blocks being appended, no sync
  - 以上4中情况的处理方式都是一样的。这里的设计将append视为普通的write，所有的case中，NN会为文件持久化一个lease，这也意味着NN自身不care文件长度而是将这个责任代理给writer/datanode。leaserecovery将这些信息从writer/datanode转移到namenode
  - 当writer/appender开始写一个block，DN将blk的数据写入到"blocksBeingWritten"目录下。当writer/appender成功完成时候，blk会从"blocksBeingWritten"转移到真实的目录下。
  - 如果writer/appender在中途挂了，那么会导致该Pipeline中各个DN在"blocksBeingWritten"的blk具有不同的长度，这时候NN会发起一个leaseRecovery来处理这个情况。
  - 如果writer/appender中途遇到错误，writer会发起这个Leaserecovery，最后NN也会知悉文件的长度和GS。
  - blk一直在"blocksBeingWritten"中，即使进行了flush调用也如此，因为flush不会使得DN产生blockRecevied调用去通知NN，这个设计使得多次调用flush不会产生对NN的压力。
Which blocks to send in a block report? those being written to, appended, sync?
1. 当一个blk被written/appended，它会处在"blocksBeingWritten"目录中，这意味着一个存在的blk将会被移到"blocksBeingWritten"去做append。而blockReport将会忽略"blocksBeingWritten"和"blocksBeingReplicated"目录。
2. 如果NN在blockReport中收到一个blk数据一个持有lease的文件，NN会将其插入到lease记录中。但是不会触发replication和corrupt检查。
  1. 如果blocksmap中记录的长度小于汇报长度，将删除所有的replica的locations，然后插入这个新的locations。
  2. 如果blocksmap中记录的长度大于汇报长度，将不会插入到blocksmap中
  3. 如果blocksmap中记录的长度等于汇报长度，将这个replica插入到blocksmap中
  4. 如果blocksmap中记录的GS小于汇报GS，将replica插入到blocksmap中，但不会创建和删除replica。这一般发生在writer/appender多次进行Recovery
What happens on a datanode restart?
1. DN重启时，首先将所有 "blocksBeingReplicated"中的blk删除。然后检查所有在"blocksBeingWritten"中的blk，如果blk的data和crc匹配，将这个blk视为有效，并将其移动到真实目录。这样就可以让blockreport将这个blk汇报到NN中。
2. 由于NN具有这个文件的lease，所以在NN收到blockReport时候，就能对这个replica进行Leaserecovery
3. 如果crc和data不匹配，那么会将data或crc进行truncate到匹配的长度，再将blk从"blocksBeingWritten"移到真实目录。
Block lengths on NN side - what should happen?
1. 由于NN并不知悉文件（具有lease）的长度，只有writer/datanode知晓。所以NN永远不会发起blk的replication/deletion。
Namenode failures
1. NN会将文件的lease进行持久化到transaction log中。当NN重启，会读取transaction log去进行Leaserecovery
Handling of blockReceived message
1. NN检查该blk的文件是否具有lease，如有，则将blk加入到blocksmap，但不检查corrupt，excess，new replication requests。
2. 如果NN中的长度小于汇报过来的长度，所以的replica的locations将从blocksmap中删除，插入这个新的locations。
3. 如果NN的要大于汇报的，那么这个replica的locations将不会被插入。
4. 如果NN的要等于汇报的，那么这个replica将会插入到blocksmap中。
5. 当文件具有lease时，NN绝不会发起blk的creation and deletion
How does lease recovery on the datanode handle partial corrupt data?
1. Leaserecovery中，PD通过调用Pipeline中的其他DN的InterDatanodeProtocol.updateBlock()方法，对Pipeline中DN的replica都设置GS和长度。
2. DN收到InterDatanodeProtocol.updateBlock()调用时候，首先检查该blk是否处于"blocksBringWritten"，如是，则检查crc和data是否匹配，否则truncate到匹配位置。
3. 最后DN将blk打上新的时间戳，并且将其从"blocksBringWritten"移到真实位置
Completion of lease recovery
1. 成功Leaserecovery将关闭该文件，关闭文件的时候NN会索引的blk进行备份检查，看看是否需要进行blk的备份。