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