编辑 - TL；DR：
所有副本节点是否必须在写入 HDFS 被视为成功之前存储文件（其所有块）？如果是，复制因子是否会影响写入延迟？
原问题：
在Hadoop 2 中，我可以通过将dfs.replication 属性设置为大于1 的值来控制数据块副本的数量（在EMR 等一些hadoop 发行版中，默认值并不总是3）。
据我了解，HDFS 的行为是同步写入第一个副本，而其他副本是流水线的，并且复制以异步方式发生。它是否正确？
如果上述情况属实，那么如果第一个节点向 namenode 发送 ack，然后在能够完成异步复制之前被陨石击中，则始终存在数据丢失的风险。
有没有办法保证至少有 X 个节点在写入成功之前写入该块？这样做是否可取？我虽然可以通过使用dfs.namenode.replication.min 属性来控制它，但我读到它只在“安全模式”下使用，因此在正常操作期间无法提供帮助。
【问题讨论】：
标签： hadoop mapreduce hdfs replication
您在哪里看到复制不可靠？来自 Cloudera 博客：
当文件被写入时，数据节点形成一个管道来写入 按顺序复制副本。数据通过管道以数据包的形式发送 （小于一个块），每一个都必须被确认才能算作 一个成功的写入。 如果一个数据节点在块被写入时失败 写入后，它会从管道中移除。当当前块有 被写入后，name节点将重新复制它以弥补 由于数据节点失败而丢失副本。后续块将是 使用具有所需数据节点数量的新管道编写
如果复制块失败，则写入将失败，HDFS 写入操作将返回错误。在成功写入所有副本之前，该操作不会被视为完成：
以下是有关 HDFS 高可用性的具体细节。 TL;DR 最后一个块在整个写入操作被认为已完成之前跨 所有 副本进行验证。仅仅“失败”也是不够的。相反，会发生自动故障转移，包括找到不同的数据节点并将失败的块写入它/它们。
块副本故障的详细信息检测：
http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/
如果正在写入的文件的最后一个块没有传播到所有 管道中的DataNodes，然后写入的数据量 当租约恢复发生时，不同的节点可能会有所不同。前 租约恢复导致文件关闭，有必要确保 最后一个块的所有副本具有相同的长度；这个流程 称为块恢复。块恢复仅在 租约恢复过程，租约恢复只触发阻塞 如果该块不在 COMPLETE 中，则恢复文件的最后一个块 状态（在后面的部分中定义）。
块失败的详细信息恢复：
在写入管道操作期间，管道中的某些 DataNode 可能 失败。当这种情况发生时，底层的写操作不能仅仅 失败。相反，HDFS 将尝试从错误中恢复以允许 管道继续运行，客户端继续写入 文件。从管道错误中恢复的机制称为 管道恢复。
我经历过数十次数据节点/块写入失败。但是很少有人经历过成功的写作“不是真的”。而那些罕见的事件是由于物理磁盘损坏而导致的 AFAICR。
【讨论】：