轉載：https://clouderatemp.wpengine.com/blog/2015/03/understanding-hdfs-recovery-processes-part-1/
很好的文章，但是要翻牆轉載給國內的夥伴，有問題請聯繫刪除
在運行或轉向可用於生產環境的Apache Hadoop時，掌握HDFS恢復過程非常重要。
HDFS的一項重要設計要求是確保連續正確的操作以支持生產部署。一個特別複雜的領域是在存在網絡和節點故障的情況下確保向HDFS寫入的正確性，其中租賃恢復，塊恢復和管道恢復過程將發揮作用。瞭解何時以及爲何調用這些恢復過程以及它們的操作，可以幫助用戶以及開發人員瞭解其HDFS羣集的結構。
在此博客文章中，您將深入瞭解這些恢復過程。我們將從快速介紹HDFS寫入管道和這些恢復過程開始，解釋塊/副本狀態和生成標記的重要概念，然後逐步完成每個恢復過程。最後，我們將列出一些相關問題，以解決並解決未解決問題。
這篇文章分爲兩個部分：第1部分將檢查租約恢復和大塊恢復的詳細信息，第2部分將檢查管道恢復的詳細信息。有興趣瞭解更多信息的讀者應參考設計規範：Append，Hflush和Read，以獲取實現細節。
背景
在HDFS中，文件分爲多個塊，並且文件訪問遵循多讀取器，單寫入器的語義。爲了滿足容錯要求，一個塊的多個副本存儲在不同的DataNode上。副本數稱爲複製因子。創建新文件塊或打開現有文件進行追加時，HDFS寫入操作將創建一個DataNodes管道來接收和存儲副本。（複製因子通常確定管道中的DataNodes數量。）隨後對該塊的寫入將通過管道（圖1）。
圖1. HDFS寫管道
對於讀取操作，客戶端選擇保存該塊副本的DataNode之一，並請求從中進行數據傳輸。
以下是兩個應用場景，重點介紹了對容錯設計要求的需求：
- HBase的區域服務器（RS）寫入其WAL（預寫日誌），WAL是有助於防止數據丟失的HDFS文件。如果RS出現故障，將啓動一個新的RS，它將通過讀取WAL文件來重建前身RS的狀態。如果在RS終止時寫管道還沒有完成，則管道中的不同DataNode可能不同步。HDFS必須確保從WAL文件中讀取所有必要的數據，以重建正確的RS狀態。
- 當Flume客戶端將數據流傳輸到HDFS文件時，即使管道中的某些DataNode發生故障或停止響應，它也必須能夠連續寫入。
租用恢復，塊恢復和管道恢復在這種情況下起作用：
- 在客戶端可以寫入HDFS文件之前，它必須獲得租約，該租約本質上是一個鎖。這樣可以確保單寫者的語義。如果客戶希望繼續寫書，則必須在預定的時間內續簽租約。如果未明確續訂租約或持有租約的客戶去世，則該租約將到期。發生這種情況時，HDFS將代表客戶端關閉文件並釋放租約，以便其他客戶端可以寫入該文件。此過程稱爲租約回收。
- 如果正在寫入的文件的最後一塊沒有傳播到管道中的所有DataNode，那麼在發生租約恢復時，寫入不同節點的數據量可能會有所不同。在租約恢復導致文件關閉之前，必須確保最後一個塊的所有副本都具有相同的長度。此過程稱爲塊恢復。塊恢復僅在租用恢復過程中觸發，而租用恢復僅在文件的最後一個塊不處於COMPLETE狀態（在後面的部分中定義）時才觸發該塊的塊恢復。
- 在寫管道操作期間，管道中的某些DataNode可能會失敗。發生這種情況時，基礎的寫操作就不會失敗。而是，HDFS將嘗試從錯誤中恢復，以允許管道繼續運行，並使客戶端繼續寫入文件。從管道錯誤中恢復的機制稱爲管道恢復。
以下各節將更詳細地說明這些過程。
塊，副本及其狀態
爲了區分NameNode上下文中的塊和DataNode上下文中的塊，我們將前者稱爲塊，將後者稱爲副本。
在數據管理部上下文中的副本可以是以下狀態之一（見枚舉ReplicaState在）：org.apache.hadoop.hdfs.server.common.HdfsServerConstants.java
- FINALIZED：當副本處於此狀態時，對副本的寫入完成，並且副本中的數據被“凍結”（長度已確定），除非重新打開副本以進行追加。具有相同世代標記（以下定義爲GS）的塊的所有最終副本應具有相同的數據。由於恢復，最終副本的GS可能會增加。
- RBW（正在複製的副本）：這是正在寫入的任何副本的狀態，無論文件是爲寫入而創建的，還是爲附加而重新打開的。RBW副本始終是打開文件的最後一塊。數據仍在寫入副本中，並且尚未完成。讀取器客戶端可以看到RBW副本的數據（不一定是全部數據）。如果發生任何故障，將嘗試將數據保留在RBW副本中。
- RWR（正在等待恢復的副本）：如果DataNode死亡並重新啓動，則其所有RBW副本將更改爲RWR狀態。RWR複製副本將變得過時並因此被丟棄，或者將參與租約恢復。
- RUR（正在恢復的副本）：非臨時副本在參與租約恢復時將變爲RUR狀態。
- TEMPORARY：創建臨時副本以進行塊複製（通過複製監視器或羣集平衡器）。它類似於RBW副本，不同之處在於其數據對於所有讀取器客戶端都是不可見的。如果塊複製失敗，則將刪除TEMPORARY副本。
在名稱節點上下文中的塊可以是在一個以下狀態（見枚舉BlockUCState在）：org.apache.hadoop.hdfs.server.common.HdfsServerConstants.java
- UNDER_CONSTRUCTION：這是寫入狀態。UNDER_CONSTRUCTION塊是打開文件的最後一塊；它的長度和標記仍然可變，並且讀者可以看到其數據（不一定是全部）。NameNode中的UNDER_CONSTRUCTION塊跟蹤寫入管道（有效RBW副本的位置）及其RWR副本的位置。
- UNDER_RECOVERY：如果相應客戶端的租約到期時，文件的最後一個塊處於UNDER_CONSTRUCTION狀態，則在塊恢復開始時它將變爲UNDER_RECOVERY狀態。
- COMMITTED：COMMITTED意味着塊的數據和生成標記不再可變（除非重新打開以追加），並且報告了GS / length相同的FINALIZED副本的DataNode的最小複製數量少於該數量。爲了滿足讀取請求，COMMITTED塊必須跟蹤RBW複製副本的位置，GS及其最終複製副本的長度。客戶端要求NameNode向文件添加新塊或關閉文件時，UNDER_CONSTRUCTION塊將更改爲COMMITTED。如果最後一個或倒數第二個塊處於COMMITTED狀態，則無法關閉文件，客戶端必須重試。
- COMPLETE：當NameNode看到匹配GS / length的FINALIZED副本的最小複製數量時，COMMITTED塊將更改爲COMPLETE 。僅當文件的所有塊都變爲COMPLETE時，才能關閉文件。即使一個塊沒有最小的複製副本數，也可能將其強制爲COMPLETE狀態，例如，當客戶端請求一個新塊，而先前的塊尚未完成時。
DataNodes將副本的狀態保留在磁盤上，但NameNode不會將塊狀態保留在磁盤上。重新啓動NameNode時，它將任何先前打開的文件的最後一個塊的狀態更改爲UNDER_CONSTRUCTION狀態，並將所有其他塊的狀態更改爲COMPLETE。
複製品和模塊的簡化狀態轉換圖如圖2和3所示。有關詳細信息，請參見設計文檔。
圖2：簡化的副本狀態轉換
圖3.簡化的塊狀態轉換
世代郵票
GS是由NameNode永久維護的每個塊的單調遞增8字節數。出於以下目的，引入了塊和副本的GS（設計規範：HDFS追加和截斷）：
- 檢測塊的陳舊副本：即，當副本GS早於塊GS時，例如，在某種程度上跳過副本的追加操作時，可能會發生這種情況。
- 在已失效很長時間的DataNode上檢測過時的副本，然後重新加入羣集。
當發生以下任何一種情況時，需要一個新的GS：
- 創建一個新文件
- 客戶端打開現有文件進行追加或截斷
- 客戶端在將數據寫入DataNode時遇到錯誤，並請求新的GS
- NameNode啓動文件的租約恢復
租賃恢復和塊恢復
租賃經理
租約由NameNode的租約管理器管理。NameNode跟蹤每個客戶端已打開以供寫入的文件。續訂租約時，客戶端不必枚舉已打開的每個文件以進行寫入。取而代之的是，它會定期向NameNode發送一個請求，以立即續訂所有請求。（請求是一條消息，它是HDFS客戶端和NameNode之間的RPC協議。）org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos.RenewLeaseResponseProto
每個NameNode管理一個HDFS命名空間，每個命名空間都有一個租約管理器來管理與該命名空間關聯的所有客戶端租約。聯合HDFS羣集可能具有多個名稱空間，每個名稱空間都有自己的租約管理器。
租約管理者在到期時間上維持軟限制（1分鐘）和硬限制（1小時）（這些限制當前不可配置），並且由租約管理者維護的所有租約都遵守相同的軟限制和硬限制。在軟限制到期之前，持有文件租約的客戶端具有對該文件的獨佔寫訪問權限。如果軟限制到期並且客戶端尚未續訂租約或關閉文件（關閉文件時將釋放文件的租約），則另一個客戶端可以強制接管租約。如果硬性限制到期並且客戶端尚未續訂租約，則HDFS會假定客戶端已退出，並將代表客戶端自動關閉文件，從而恢復租約。
一個客戶端持有文件租賃的事實並不能阻止其他客戶端讀取該文件，即使一個客戶端正在寫入文件，文件也可能具有許多併發讀取器。
租賃管理器支持的操作包括：
- 爲客戶端和路徑添加租約（如果客戶端已經具有租約，則將路徑添加到租約，否則，將創建新的租約並將路徑添加到租約）
- 刪除客戶端和路徑的租約（如果這是租約中的最後一條路徑，則會刪除租約）
- 檢查軟限制和/或硬限制是否已過期，以及
- 爲給定客戶續訂租約。
租約管理器具有一個監視線程，該線程定期（當前每2秒一次）檢查任何租約是否具有過期的硬限制，如果是，它將觸發這些租約中文件的租約恢復過程。
HDFS客戶端通過維護用戶列表並在每個NameNode上爲每個用戶運行一個線程的類來更新其租約。該線程定期使用NameNode進行檢入，並在租約期結束一半時續訂所有客戶端的租約。org.apache.hadoop.hdfs.LeaseRenewer.LeaseRenewer
（注意：HDFS客戶端僅與一個NameNode關聯；請參閱的構造函數）。如果同一應用程序要訪問聯合集羣中不同NameNodes管理的不同文件，則需要爲每個NameNode創建一個客戶端。）org.apache.hadoop.hdfs.DFSClient
租賃回收流程
租約恢復過程在NameNode上觸發，以通過硬限制到期後的監視線程，或當軟限制到期時客戶端嘗試從另一客戶端接管租約時，爲給定客戶端恢復租約。它檢查由同一客戶端打開的每個文件以供寫入，如果文件的最後一個塊不處於COMPLETE狀態，則對該文件執行塊恢復，然後關閉該文件。僅在恢復文件的租約時才觸發文件的塊恢復。
以下是給定文件f的租約恢復算法。客戶端死亡時，將相同的算法應用於客戶端打開以進行寫入的每個文件。
- 獲取包含f的最後一塊的DataNode。
- 將其中一個DataNode分配爲主要DataNode p。
- p從NameNode獲得新一代的郵票。
- p從每個DataNode獲取塊信息。
- p計算最小塊長度。
- p 使用新生成的標記和最小的塊長度更新具有有效生成標記的DataNodes。
- p確認NameNode更新結果。
- NameNode更新BlockInfo。
- NameNode刪除f的租約（其他編寫者現在可以獲取寫給f的租約）。
- NameNode提交更改以編輯日誌。
步驟3至7是算法的塊恢復部分。如果文件需要塊恢復，則NameNode會選擇一個具有該文件最後一個塊的副本的主DataNode，並告訴該DataNode與其他DataNode協調該塊恢復工作。完成後，該DataNode將報告回NameNode。然後，NameNode更新此塊的內部狀態，刪除租約，並將更改提交給編輯日誌。
有時，管理員需要在硬限制到期之前強行恢復文件的租約。有一個CLI調試命令（從Hadoop版本2.7和CDH 5.3開始）可用於此目的：
hdfs debug recoverLease [-path] [-retries ]
結論
租約恢復，塊恢復和管道恢復對於HDFS容錯至關重要。它們共同確保即使在存在網絡和節點故障的情況下，寫入也能在HDFS中持久且一致。
現在，您應該更好地瞭解何時以及爲何調用租約恢復和塊恢復以及它們的作用。在第2部分中，我們將探討管道恢復。