Namenode當中的兩個文件：edits和fsimage，fsimage文件包含了文件系統中的所有目錄和文件inode的序列化信息。每個inode是一個文件或者目錄的元數據的內部描述方式。因此該文件相當重要。fsimage文件是文件系統元數據的一個永久性檢查點，並非每一個寫操作都會更新這個文件，因為fsimage是一個大型文件，有時候甚至可高達幾個G，如果頻繁的對該文件進行寫操作的話，會使系統運行極為緩慢。
同樣的，namenode節點上的edits文件也無限的增長。盡管這種無限增長的情況對於namenode的運行來說是沒有影響的。但是由於需要恢復非常長的編輯日志中的各項操作，namenode的重啟操作會變得比較慢。（這里需要說明一下的是：集群當中，每一次重啟namenode的時候，namenode都會加載並執行edits中的各項操作。）
因此hadoop采用的解決方案是：運行輔助namenode，為主namenode內存中的文件系統元數據創建檢查點。SecondaryNameNode 檢查點的具體步驟:
1、SecondaryNameNode 請求主 namenode 停止使用 edits 文件，暫時將新的操作記錄到 edits.new 文件中；
2、SecondaryNameNode 以 http get 復制 主 namenode 中的 fsimage, edits 文件；
3、SecondaryNameNode 將 fsimage 載入到內存，並逐一執行 edits 文件中的操作，創建新的fsimage.ckpt 文件；
4、SecondaryNameNode 以 http post 方式將新的fsimage.ckpt 復制到主namenode.
5、主 namenode 將 fsimage.ckpt改為新的fsimag來替換原來舊的fsimage 文件，同時將 edits.new 文件重命名為 edits來替換原來舊的edits文件。並更新 fstime 文件來記錄下次檢查點時間。
6、SecondaryNameNode 保存最新檢查點的目錄與 NameNode 的目錄結構相同。 所以 NameNode 可以在需要的時候讀取 SecondaryNameNode上的檢查點鏡像。
Secondary Namenode定期地從Namenode上獲取元數據。通過這樣一番操作，就避免了Namenode的edits日志的無限增長，加速Namenode的啟動過程。
講到這里，很多人把secondarynamenode我無以為是第二個namenode，其實並不是這樣子的，實際上secondarynamenode主要是為了分擔主namendoe的fsimage和edits合並工作。本質上secondarynamenode是namenode一個組成部分與主namenode同時存在的。並且如果沒有對Secondary Namenode進行參數設置的話，默認是會在namenode[0.0.0.0]節點上自行啟動的。
但是Scondary Namenode有其自身的弱點，如checkpoint數據較舊，數據不一致等，新版本的hadoop已經把它放棄了，轉而使用更加高效的Backup Node。
Hadoop2.x以后支持HA的部署，這個HA部署跟利用secondarynamenode來恢復主namenode是兩種不同的方式。HA可以實現無縫接管，副節點隨時處在待命的狀態，主副namenode是可以自動切換。而利用secondarynamenode來恢復主namenode是需要手動恢復的，並且恢復的數據可能存在不一致性，其不一致性的原因主要是在檢查點那一段時間內的數據可能會丟失，造成的數據不一致性。
在這里還需要注意一點：SecondaryNameNode的進程並不是一直處於開啟狀態的，SecondaryNameNode進程啟動是由兩個配置參數控制的。只有滿足了這個兩個條件之一才會啟動，但是他的守護進程是一直在開啟的。
（1）fs.checkpoint.period，指定連續兩次檢查點的最大時間間隔， 默認值是1小時。
（2）fs.checkpoint.size 定義了 edits 日志文件的最大值，一旦超過這個值會導致強制執行檢查點（即使沒到檢查點的最大時間間隔）。默認值是64MB。
因此，創建檢查點的過程不僅為主namenode創建檢查點數據，使得SecondaryNameNode最終有一份檢查點數據，這份數據可以用作namenode元數據的備份。
下面討論一下SecondaryNameNode部署在那個節點上的問題：
如果SecondaryNameNode部署在datanode節點上的話，我們主要考慮的是cpu和內存的問題。下面我們來分析一下datanode內存使用情況：首先hadoop默認是給每一個進行分配1000M的內存，假如我們是八核的處理器，map和reducer的最大數目設置為7個，每個任務分配的是200M的內存，那么需要的最大內存為：14*400M，再加上datanode和tasktracker進行各1000M，共計：7600M。若datanode采用默認參數的話，默認map和reducer的最大數目是2.則對應的需要的內存是：2800M
如果SecondaryNameNode部署在namenode節點上的話，此時namenode內存消耗是：
僅僅一個namenode的進程：默認是1000M（但是實際情況可能不同）。但是這樣部署都不是很合理，因為如果namenode磁盤壞掉，此時SecondaryNameNode的備份檢查點數據也跟着壞掉，這樣子就沒有達到我們最終的目的。