HDFS 重要機制之 checkpoint

hdpdriver發表於2024-10-22

核心概念

hdfs checkpoint 機制對於 namenode 後設資料的保護至關重要, 是否正常完成檢查點是評估 hdfs 叢集健康度和風險的重要指標

  • editslog : 對 hdfs 操作的事務記錄，類似於 wal ，edit log檔案以 edits_ 開頭，後面跟一個txid範圍段，並且多個edit log之間首尾相連,正在使用的 edit log 名字為 edits_inprogress_txid（dfs.namenode.edits.dir）
  • fsimage：檔案系統的後設資料，snn會定時合併將記憶體中的後設資料落盤生成新的fsimage，預設會儲存兩個fsimage檔案，檔案格式為fsimage_txid（dfs.namenode.name.dir）
  • seen_txid：記錄了最後一次 checkpoint 或者 edit 回滾（將 edits_inprogress_xxx 檔案回滾成一個新的 Edits 檔案）之後的 transaction ID。主要用來檢查 NameNode 啟動過程中 Edits 檔案是否有丟失的情況

Pasted image 20221207103015.png

檢查點將從舊的 fsimage 和編輯日誌進行合併,建立一個新的 fsimage

Pasted image 20221128143125.png

checkpoint 觸發由三個引數控制

dfs.namenode.checkpoint.period
dfs.namenode.checkpoint.txns
dfs.namenode.checkpoint.check.period

HA 叢集的 checkpoint 過程

Pasted image 20221128160510.png

這裡 standby namenode 稱為 SBNN，active namenode 稱為 ANN

  1. SBNN 檢視是否滿足建立檢查點的條件（距離上次 checkpoint 的時間間隔大於等於 dfs.namenode.checkpoint.period
    edits log 中的事務條數達到 dfs.namenode.checkpoint.txns 限制）
  2. SBNN 將記憶體中當前的狀態儲存成一個新的檔案，命名為fsimage.ckpt_txid。其中 txid 是最後一個 edit log 中的最後一條事務的 ID（transaction ID，不包括 inprogress）。然後為該 fsimage 檔案建立一個MD5 檔案，並將 fsimage 檔案重新命名為 fsimage_txid。
  3. SBNN 向 ANN 傳送一條 HTTP GET 請求。請求中包含了 SBNN 的域名，埠以及新 fsimage 的 txid。
    ANN 收到請求後，用獲取到的資訊反過來向 SBNN 再傳送一條 HTTP GET 請求，獲取新的 fsimage 檔案。這個新的 fsimage 檔案傳輸到 ANN 上後，也是先命名為 fsimage.ckpt_txid，併為它建立一個 MD5 檔案。然後再改名為 fsimage_txid，checkpoint過程完成。

生產實踐

對於大規模的叢集,如果長期未成功完成 checkpoint ,那麼會積累非常多的 editlog 檔案.重啟 namenode 的時候,必須要回放 editlog ,以使記憶體中的目錄樹恢復到最新狀態.回放 editlog 必然是逐個檔案來回放的,此時如果積累了大量的 editlog 檔案,那麼這個過程會長達三個小時以上.增大 namenode 的記憶體可以適當加快這個過程.

  • edit 檔案堆積處理

如果長期 edit 日誌檔案有堆積,可以進入安全模式後,手動執行 saveNamespace 命令來進行一次合併. 但是線上環境中,不能進入安全模式,這個時候可以透過重啟 standynamenode 來觸發一次 checkpoint

遇到過一次線上問題,由於 ann 鎖的問題導致 sbnn 無法 put fsimage 到 ann,重啟 sbnn 也無法完成最終完成 checkpoint ,這個時候可以等 sbnn namespace 正常啟動後,然後進行一次主備切換,使之前鎖住的 ann 變成了 sbnn,然後重啟這個節點,此時就能夠完成 checkpoint 了,堆積的 edit 檔案也能夠被清理了

  • 手動 checkpoint 方法

hdfs dfsadmin -fs 10.0.0.26:4007 -safemode enter
hdfs dfsadmin -fs 10.0.0.26:4007 -saveNamespace
hdfs dfsadmin -fs 10.0.0.26:4007 -safemode leave
hdfs dfsadmin -safemode forceExit //強制退出安全模式

  • 監控 checkpoint

有兩個重要指標:

  1. TransactionsSinceLastCheckpoint 表示距離上次checkpoint的事務數，建議超過3000000 告警
  2. LastCheckpointTime 上次checkpoint的時間，建議距離當前時間超過12小時告警
  • 謹慎重啟 NameNode

hdfs 在重啟流程需要載入 edit logs,如果 edit logs 遺留有沒被注意到的錯誤, hdfs 將會無法啟動完成,導致生產事故

比較常見的原因是:
誤刪editslog、JournalNode節點有斷電、資料目錄磁碟佔滿、網路持續異常等

常見報錯如下:

java.io.IOException: Gap in transactions. Expected to be able to read up until at least txid 813248390 but unable to find any edit logs containing txid 363417469

可以動態開啟DEBUG 日誌級別定位報錯位置

解決辦法：

  1. 檢視其它的JournalNode的資料目錄或NameNode資料目錄中，有沒有連續的該序號相關的連續的edits檔案。如果可以找到，複製一個連續的片段到該JournalNode
  2. 使用namenode recovery 模式 跳過 edits 錯誤
  3. 使用 edits viewer 修復錯誤 edit 檔案
  4. 從 active nn 恢復 standy nn
  5. 以上如不能解決,只能從fsimage恢復namenode 來上線 namenode

高頻故障 issue:
https://issues.apache.org/jira/browse/HDFS-15175

相關文章