Namenode工作機制及HDFS的安全模式
檔案系統映像 ( fsimage ) 和 編輯日誌 ( edits )
當建立或移動檔案時 ,會把操作記錄在編輯日誌中 ,NameNode 在記憶體中維護檔案系統的元資料 ,當編輯日誌被修改時 ,相關的元資料資訊也同步更新
每個 fsimage 檔案都是檔案系統元資料的一個完整的永久性檢查點 ,並非每個寫操作都會更新該檔案 ,因為 fsimage 可能會很大 ,如果頻繁執行寫操作 ,會使系統執行極為緩慢
如果 NameNode 發生故障時 ,最近的 fsimage 檔案將被載入到記憶體以重構元資料最近的狀態 ,再從相關點開始向前執行編輯日誌中記錄的每個事務
編輯日誌會無限增長 ,執行這些事務時 NameNode 的重啟操作會比較慢 解決方案就是使用 SecondNameNode
流程 :
- SecondNameNode 請求 NameNode 停止使用正在進行的 edits 檔案 ,這樣新的編輯操作記錄到一個新檔案中 ,主 Namenode 還會更新所有儲存目錄中的 see_txid 檔案
- SecondNameNode 從主 NamoNode 獲取最近的 fsimage 和 edits 檔案 ( 採用 HTTP GET )
- SecondNameNode 將 fsimage 檔案載入記憶體 ,逐一執行 edits 檔案中的事務 ,建立新的合併後的 fsimage 檔案
- SecondNameNode 將新的 fsimage 檔案傳送回主 NameNode ( 使用 HTTP PUT ) ,主 NameNode 將其儲存為臨時的 .ckpt 檔案
- NameNode 重新命名臨時的 fsimage 檔案 ,便於日後使用
兩個相關引數
dfs.namenode.checkpoint.check.period = 60 # 檢查觸發條件是否滿足的頻率
dfs.namenode.checkpoint.dir = 檔案儲存位置
HDFS的安全模式在做什麼?
NameNode 啟動時 ,首先將映像檔案 ( fsimage ) 載入記憶體 ,並執行編輯日誌 ( edits ) 中的各項編輯操作 ,一旦記憶體中成功建立檔案系統元資料映像 ,則建立一個新的 fsimage 檔案 ( 不借助 SecondNameNode )
和一個空的編輯日誌 ,這個過程中 NameNode 執行在安全模式 ,意味著 NameNode 的檔案系統對於客戶端來說是隻讀的
檢查當前可用 Block 塊 佔比 ,如果達不到配置檔案所設定的佔比數 ,則處於安全模式
檢查 是否有 DataNode 沒有啟動
hdfs fsck / -delete 刪除錯誤的塊
檔案系統檢查工具 hdfs fsck /
三個datanode中當有一個datanode出現錯誤時會怎樣
Namenode會通過心跳機制感知到datanode下線
會將這個datanode上的block塊在叢集中重新複製一份，恢復檔案的副本數量
會引發運維團隊快速響應，派出同事對下線datanode進行檢測和修復，然後重新上線