HDFS Append 设计文档的QA(HDFS-265:Revisit append/Questions about the "Append Design")

转帖请注明来自本空间地址:
http://blog.csdn.net/chenpingbupt
本文是关于Append设计文档中一些设计点的QA,原文的地址已经不记得是从HDFS中的那个Jira上看到的了,可以参考Append设计文档来看:
https://issues.apache.org/jira/secure/attachment/12445209/appendDesign3.pdf
译文如下:
  1. 以下场景中,可能发生那些失败,以及如何处理?
    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的压力。
  2. 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
  3. 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"移到真实目录。
  4. Block lengths on NN side  - what should happen?
    1. 由于NN并不知悉文件(具有lease)的长度,只有writer/datanode知晓。所以NN永远不会发起blk的replication/deletion。
  5. Namenode failures
    1. NN会将文件的lease进行持久化到transaction log中。当NN重启,会读取transaction log去进行Leaserecovery
  6. 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
  7. 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"移到真实位置
  8. Completion of lease recovery
    1. 成功Leaserecovery将关闭该文件,关闭文件的时候NN会索引的blk进行备份检查,看看是否需要进行blk的备份。

你可能感兴趣的:(文档)