- 為節省篇幅，將SecondaryNameNode簡稱SNN，NameNode簡稱NN。
NN與fsimage、edits文件
NN負責管理HDFS中所有的元數據，包括但不限於文件/目錄結構、文件權限、塊ID/大小/數量、副本策略等等。客戶端執行讀寫操作前，先從NN獲得元數據。當NN在運行時，元數據都是保存在內存中，以保證響應時間。
顯然，元數據只保留在內存中是非常不可靠的，所以也需要持久化到磁盤。NN內部有兩類文件用於持久化元數據：
fsimage文件(鏡像文件)，以fsimage_為前綴，是序列化存儲的元數據的整體快照；
edits文件（又稱edit log），以edits_為前綴，是順序存儲的元數據的增量修改（即客戶端寫入操作）日志。
這兩類文件均存儲在${dfs.namenode.name.dir}/current/路徑下，如下所示。
[root@master current]# pwd
/usr/local/src/hadoop-2.6.1/dfs/name/current
[root@master current]# ls -l
total 1040
-rw-r--r-- 1 root root 1048576 Aug 18 02:07 edits_inprogress_0000000000000000001
-rw-r--r-- 1 root root 351 Aug 18 01:59 fsimage_0000000000000000000
-rw-r--r-- 1 root root 62 Aug 18 01:59 fsimage_0000000000000000000.md5
-rw-r--r-- 1 root root 2 Aug 18 02:00 seen_txid
-rw-r--r-- 1 root root 206 Aug 18 01:59 VERSION
可見，當前正在寫入的edits文件名會有"inprogress"標識，而seen_txid文件保存的就是當前正在寫入的edits文件的ID。
在任意時刻，最近的fsimage和edits文件的內容加起來就是全量元數據。NN在啟動時，就會將最近的fsimage文件加載到內存，並重放它之后記錄的edits文件，恢復元數據的現場。
SNN與checkpoint過程
為了避免edits文件過大，以及縮短NN啟動時恢復元數據的時間，我們需要定期地將edits文件合並到fsimage文件，該合並過程叫做checkpoint（這個詞是真正被用爛了哈）。
由於NN的負擔已經比較重，再讓它來進行I/O密集型的文件合並操作就不太科學了，所以Hadoop引入了SNN負責這件事。也就是說，SNN是輔助NN進行checkpoint操作的角色。
checkpoint的觸發由hdfs-site.xml中的兩個參數來控制。
dfs.namenode.checkpoint.period：觸發checkpoint的周期長度，默認為1小時。
dfs.namenode.checkpoint.txns：兩次checkpoint之間最大允許進行的操作數，默認為100萬。
只要滿足上述兩個參數的條件之一，就會觸發checkpoint過程，敘述如下：
NN生成新的edits_inprogress文件，后續的修改日志將寫入該文件中，之前正在寫的edits文件即為待合並狀態。
將待合並的edits文件和fsimage文件一起復制到SNN本地。
SNN像NN啟動時一樣，將fsimage文件加載到內存，並重放edits文件進行合並。生成合並結果為fsimage.chkpoint文件。
SNN將fsimage.chkpoint復制回NN，並重命名為正式的fsimage文件名。
Hadoop官方給出的圖示如下。雖然文件名稱不同，但思想是一樣的。
如果開啟了NN高可用呢？
上面說的都是集群只有一個NN的情況。如果有兩個NN並且開啟了HA的話，SNN就沒用了——checkpoint過程會直接交給Standby NN來負責。Active NN會將edits文件同時寫到本地與共享存儲（QJM方案就是JournalNode集群）上去，Standby NN從JournalNode集群拉取edits文件進行合並，並保持fsimage文件與Active NN的同步。