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。