hadoop的checkpoint
SecondaryNameNode
通過定時 查詢 namenode上的edit logs 來保證 fsimage的及時更新 時刻複製 active的Namenode工作節點的快照 。
合併namenode 的 edit log 合併到 fsimage上
1.定時獲取active狀態的namenode節點的 edit logs 並更新 到 fsimage [Secondary自己的image快照 ](根據操作id來合併 從自己快照的最新的操作合併edits的操作只合並快照以後的)
2.一旦有了新的fsimage文件，它將其拷貝會 NameNode 中
3.NameNode 在下次重啓會使用這個新的fsimage文件 減少重啓時間
NameNode 的 edit log 中是什麼時候發生改變
我們往DataNode放入文件時 ，DataNode 會和NameNode通信 告訴NameNode 什麼文件的第幾個block放在它那裏 。NameNode會將其寫入到edit log。
高可用集羣
兩個NameNode爲了數據同步，會通過一組稱作JournalNodes的獨立進程進行相互通信。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。standby狀態的NameNode有能力讀取JournalNodes中的變更信息，並且一直監控edit log的變化，把變化應用於自己的命名空間。standby可以確保在集羣出錯時，命名空間狀態已經完全同步了。
運行JournalNodes的計算機。JournalNode守護程序相對輕量級，因此這些守護程序可以合理地與其他Hadoop守護程序並置在機器上，例如NameNodes，JobTracker或YARN ResourceManager。**注意：**必須至少有3個JournalNode守護進程，因爲編輯日誌修改必須寫入大多數JN。這將允許系統容忍單個機器的故障。您也可以運行3個以上的JournalNodes，但爲了實際增加系統可以容忍的失敗次數，您應該運行奇數個JN（即3,5,7等）。請注意，當使用N JournalNodes運行時，系統最多可以容忍（N-1）/ 2個故障並繼續正常運行。
JournalNode的工作原理
- hadoop.journalnode.edits.dir 配置Journal共享目錄位置
- 只有活躍狀態的節點有權對journal的共享目錄進行更改 在更改時如果有半數目以上的Journalnode節點更改成功就是爲更改成功。
- standby狀態的NameNode有能力讀取JournalNodes中的變更信息，並且一直監控edit log的變化，把變化應用於自己的命名空間
- 確保快速切換，standby狀態的NameNode有必要知道集羣中所有數據塊的位置。爲了做到這點，所有的datanodes必須配置兩個NameNode的地址，發送數據塊位置信息和心跳給他們兩個。
- 運行的JournalNode進程非常輕量，可以部署在其他的服務器上。注意：必須允許至少3個節點。當然可以運行更多，但是必須是奇數個，如3、5、7、9個等等。當運行N個節點時，系統可以容忍至少(N-1)/2(N至少爲3)個節點失敗而不影響正常運行。
- standby狀態的NameNode可以完成checkpoint操作，因此沒必要配置Secondary NameNode、CheckpointNode、BackupNode。如果真的配置了，還會報錯。
