HDFS Pipeline Recovery

pipeline 写入的三个阶段

1.pipeline setup：Client 发送一个写请求沿着 pipeline 传递下去，最后一个 DataNode 收到后发回一个确认消息。Client 收到确认后，pipeline 设置准备完毕，可以往里面发送数据了。

2.data streaming：Client 将一个 block 拆分为多个 packet 来发送（默认一个 block 64MB，太大所以需要拆分）。Client 持续往 pipeline 发送 packet，在收到 packet ack 之前允许发送 n 个 packet，n 就是 Client 的发送窗口大小（类似 TCP 滑动窗口）

3.close：Client 在所有发出的 packet 都收到确认后发送一个 Close 请求，
pipeline 上的 DataNode 收到 Close 后将相应 replica 修改为 FINALIZED 状态，并向 NameNode 发送 block 报告。NameNode 将根据报告的 FINALIZED 状态的 replica 数量是否达到最小副本要求来改变相应 block 状态为 COMPLETE。

 

HDFS Pipeline Recovery

 

从 pipeline setup 错误中恢复

在 pipeline 准备阶段发生错误，分两种情况：

1. 新写文件：Client 重新请求 NameNode 分配 block 和 DataNodes，重新设置 pipeline。
2. 追加文件：Client 从 pipeline 中移除出错的 DataNode，然后继续。

从 data streaming 错误中恢复

1. 当 pipeline 中的某个 DataNode 检测到写入磁盘出错（可能是磁盘故障），它自动退出 pipeline，关闭相关的 TCP 连接。
2. 当 Client 检测到 pipeline 有 DataNode 出错，先停止发送数据，并基于剩下正常的 DataNode 重新构建 pipeline 再继续发送数据。
3. Client 恢复发送数据后，从没有收到确认的 packet 开始重发，其中有些 packet 前面的 DataNode 可能已经收过了，则忽略存储过程直接传递到下游节点。

从 close 错误中恢复

到了 close 阶段才出错，实际数据已经全部写入了 DataNodes 中，所以影响很小了。Client 依然根据剩下正常的 DataNode 重建 pipeline，让剩下的 DataNode 继续完成 close 阶段需要做的工作。

以上就是 pipeline recovery 三个阶段的处理过程，这里还有点小小的细节可说。
当 pipeline 中一个 DataNode 挂了，Client 重建 pipeline 时是可以移除挂了的 DataNode，也可以使用新的 DataNode 来替换。这里有策略是可配置的，称为 DataNode Replacement Policy upon Failure，包括下面几种情况：

1. NEVER：从不替换，针对 Client 的行为
2. DISABLE：禁止替换，DataNode 服务端抛出异常，表现行为类似 Client 的 NEVER 策略
3. DEFAULT：默认根据副本数要求来决定，简单来说若配置的副本数为 3，如果坏了 2 个 DataNode，则会替换，否则不替换
4. ALWAYS：总是替换