它出現在Hadoop1.x版本中，又稱輔助NameNode，在Hadoop2.x以后的版本中此角色消失。如果充當datanode節點的一台機器宕機或者損害，其數據不會丟失，因為備份數據還存在於其他的datanode中。但是，如果充當namenode節點的機器宕機或損害導致文件系統無法使用，那么文件系統上的所有文件將會丟失，因為我們不知道如何根據datanode的塊重建文件。因此，對namenode實現容錯非常重要。Hadoop提供了兩種機制實現高容錯性。
第一種機制是備份那些組成文件系統元數據持久狀態的文件。Hadoop可以通過配置使namenode在多個文件系統上保存元數據的持久化狀態。這些寫操作是實時同步的，是原子操作。一般的配置是，將持久狀態寫入本地磁盤的同時，寫入一個遠程掛載的網絡文件系統(NFS)。
另一種可行的方法是運行一個輔助namenode，但是它不能用作namenode，這個輔助namenode，在hadoop1.x中被稱為secondary namenode，在hadoop2.x中，利用高可用（HA）解決單點故障問題。
Secondary namenode，以下簡稱SN，其重要作用是定期將編輯日志和元數據信息合並，防止編輯日志文件過大，並且能保證其信息與namenode信息保持一致。SN一般在另一台單獨的物理計算機上運行，因為它需要占用大量CPU時間來與namenode進行合並操作，一般情況是單獨開一個線程來執行操作過程。但是，SN保存的信息永遠是滯后於namenode，所以在namenode失效時，難免會丟失部分數據。在這種情況下，一般把存儲在NFS上的namenode元數據復制到SN並作為新的namenode。SN不是namenode的備份，可以作為備份。SN主要工作是幫助NN合並edits和fsimage，減少namenode的啟動時間。
它不是NameNode的備份，但可以做備份，其主要工作是幫助NameNode合並editslog，減少NameNode的啟動時間。SecondaryNameNode執行合並的時機決定於：
（1） 配置文件設置的時間間隔fs.checkpoint.period，默認為3600秒。
（2） 配置文件設置edits log大小fs.checkpoint.size,規定edits文件的最大值默認是64MB。
圖1.6 SecondaryNameNode合並流程
如上圖，當namenode運行了3600s后，SN取出fsimage和edits，合並，更新fsimage，命名為fsimage.ckpt，將fsimage.ckpt文件傳入namenode中，合並過程中，客戶端會繼續上傳文件。同時，namenode會創建新的edits.new文件，將合並過程中，產生的日志存入edits.new，namenode將 fsimage.ckpt,更名為fsimage，edits.new更名為edits。
如果在合並過程中，namenode損壞，那么，丟失了在合並過程中產生的edits.new,因此namenode失效時，難免會丟失部分數據。