HDFS复制因子 - 最大限度地减少数据丢失的风险

Question

编辑 - TL; DR：

做所有副本节点必须存储到HDFS写被认为是成功的前一个文件（所有块）？如果是这样，复制因素是否会影响写入延迟？

原始的问题：

在Hadoop 2我可以由dfs.replication属性设置为大于1的值来控制数据块的副本数（默认为不总是在一些hadoop的分布等EMR 3）。

我的理解是HDFS行为是同步写入第一个副本，而其他行为是管道化的，并且复制是以异步方式进行的。它是否正确？

如果以上情况属实，那么如果第一个节点向名称节点发送ack，然后在能够完成异步复制之前被陨石击中，则总会有数据丢失的风险。

有没有办法保证在写入被认为成功之前至少有X个节点写入该块？这样做是明智的吗？我虽然我可以通过使用dfs.namenode.replication.min属性来控制这一点，但我读到它仅在“安全模式”下使用，因此在正常操作期间无法帮助。

Answer 1

您从哪里看到复制不可靠？来自Cloudera博客：

正在写入文件时，数据节点形成一个管道，按顺序写入 副本。通过数据包 （小于一个块），通过流水线发送数据，每个数据包必须被确认为计数为 成功写入。如果数据节点在写入块为 时发生故障，则将其从管道中删除。当当前块已 被写入，thename节点将重新复制它来弥补缺少 副本由于失败的数据node.Subsequent块将 使用与所需数量的数据节点的新管道书面

如果复制块失败，则写入操作将失败，并且HDFS写入操作会返回错误。直到所有副本都被成功写入，该操作才被视为已完成：

以下是有关HDFS高可用性的具体详细信息。 TL; DR在整个写入操作被认为完成之前，最后一个块在全部副本上被验证。仅仅“失败”也是不够的。而是发生自动故障转移，包括查找不同的datanode并将失败的块写入它/它们。上块副本失败

详细检测：

http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/

如果写入该文件的最后一个块不被传播到所有 的DataNodes的管道，然后写入的数据量到 不同的节点可能会不同，当租约恢复发生时。在 租约恢复导致文件关闭之前，有必要确保 所有最后一个块的副本具有相同的长度;这个过程 被称为块恢复。仅在 租约恢复过程中才会触发块恢复，如果该块未处于COMPLETE 状态（稍后部分中定义），则租约恢复仅会触发块的最后一个块的 恢复。分块破坏恢复

详情：

在写流水线作业，管道中的一些可能的DataNodes失败 。发生这种情况时，底层的写入操作不能只是 失败。相反，HDFS将尝试从错误中恢复以允许 管道继续运行，并且客户端继续写入 文件。从管道错误中恢复的机制称为 管道恢复。

我遇到过datanode/block写入失败次数的问题。但很少有人认为成功的写作“不是真的”。而那些罕见的事件是由于物理磁盘上的腐败造成的AFAICR。