1.概述
最近有朋友問我Secondary NameNode的作用，是不是NameNode的備份？是不是為了防止NameNode的單點問題？確實，剛接觸Hadoop，從字面上看，很容易會把Secondary NameNode當作備份節點；其實，這是一個誤區，我們不能從字面來理解，閱讀官方文檔，我們可以知道，其實並不是這么回事，下面就來贅述下Secondary NameNode的作用。
2.Secondary NameNode？
在Hadoop中，有一些命名模塊不那么盡人意，Secondary NameNode就是一個典型的例子之一。從它的名字上看，它給人的感覺就像是NameNode的備份節點，但實際上卻不是。很多Hadoop的入門者都很疑惑，Secondary NameNode究竟在其中起什么作用，它在HDFS中所扮演的角色是什么。下面，我就來解釋下：
從名字來看，它確實與NameNode有點關系；因此，在深入了解Secondary NameNode之前，我們先來看看NameNode是做什么的。
2.1NameNode
NameNode主要是用來保存HDFS的元數據信息，比如命名空間信息，塊信息等等。當它運行的時候，這些信息是存在內存中的。但是這些信息也可以持久化到磁盤上。如下圖所示：
上圖展示來NameNode怎么把元數據保存到磁盤上，這里有兩個不同的文件：
- fsimage：它是NameNode啟動時對整個文件系統的快照。
- edits：它是在NameNode啟動后，對文件系統的改動序列。
只有在NameNode重啟時，edits才會合並到fsimage文件中，從而得到一個文件系統的最新快照。但是在生產環境集群中的NameNode是很少重啟的，這意味者當NameNode運行來很長時間后，edits文件會變的很大。在這種情況下就會出現下面這些問題：
- edits文件會變的很大，如何去管理這個文件？
- NameNode的重啟會花費很長的時間，因為有很多改動要合並到fsimage文件上。
- 如果NameNode宕掉了，那我們就丟失了很多改動，因為此時的fsimage文件時間戳比較舊。
因此為了克服這個問題，我們需要一個易於管理的機制來幫助我們減小edits文件的大小和得到一個最新的fsimage文件，這樣也會減小在NameNode上的壓力。而Secondary NameNode就是為了幫助解決上述問題提出的，它的職責是合並NameNode的edits到fsimage文件中。如圖所示：
上圖的工作原理，我這里也贅述下：
- 首先，它定時到NameNode去獲取edits，並更新到fsimage上。
- 一旦它有新的fsimage文件，它將其拷貝回NameNode上。
- NameNode在下次重啟時回使用這個新的fsimage文件，從而減少重啟的時間。
Secondary NameNode的整個目的在HDFS中提供一個Checkpoint Node，通過閱讀官方文檔可以清晰的知道，它只是NameNode的一個助手節點，這也是它在社區內被認為是Checkpoint Node的原因。
現在，我們明白Secondary NameNode所做的是在文件系統這設置一個Checkpoint來幫助NameNode更好的工作；它不是取代NameNode，也不是NameNode的備份。
Secondary NameNode的檢查點進程啟動，是由兩個配置參數控制的：
- fs.checkpoint.period，指定連續兩次檢查點的最大時間間隔， 默認值是1小時。
- fs.checkpoint.size定義了edits日志文件的最大值，一旦超過這個值會導致強制執行檢查點（即使沒到檢查點的最大時間間隔）。默認值是64MB。
如果NameNode上除了最新的檢查點以外，所有的其他的歷史鏡像和edits文件都丟失了， NameNode可以引入這個最新的檢查點。以下操作可以實現這個功能：
- 在配置參數dfs.name.dir指定的位置建立一個空文件夾；
- 把檢查點目錄的位置賦值給配置參數fs.checkpoint.dir；
- 啟動NameNode，並加上-importCheckpoint。
NameNode會從fs.checkpoint.dir目錄讀取檢查點，並把它保存在dfs.name.dir目錄下。如果dfs.name.dir目錄下有合法的鏡像文件，NameNode會啟動失敗。 NameNode會檢查fs.checkpoint.dir目錄下鏡像文件的一致性，但是不會去改動它。
注：關於NameNode是什么時候將改動寫到edit logs中的？這個操作實際上是由DataNode的寫操作觸發的，當我們往DataNode寫文件時，DataNode會跟NameNode通信，告訴NameNode什么文件的第幾個block放在它那里，NameNode這個時候會將這些元數據信息寫到edit logs文件中。
下面附上官方文檔說明：
The NameNode stores modifications to the file system as a log appended to a native file system file, edits. When a NameNode starts up, it reads HDFS state from an image file, fsimage, and then applies edits from the edits log file. It then writes new HDFS state to the fsimage and starts normal operation with an empty edits file. Since NameNode merges fsimage and edits files only during start up, the edits log file could get verylarge over time on a busy cluster. Another side effect of a larger edits file is that next restart of NameNode takes longer.
The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run ona different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.
The start of the checkpoint process on the secondary NameNode is controlled by two configuration parameters.
* dfs.namenode.checkpoint.period, set to 1 hour by default, specifies the maximum delay between two consecutive checkpoints, and
* dfs.namenode.checkpoint.txns, set to 1 million by default, defines the number of uncheckpointed transactions on the NameNode which will force an urgent checkpoint, even if the checkpoint period has not been reached.
The secondary NameNode stores the latest checkpoint in a directory which is structured the same way as the primary NameNode's directory. So that the check pointed image is always ready to be read by the primary NameNode if necessary.
參考地址：http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
3.總結
這篇文章就和大家分享到這里，若在閱讀過程中有什么疑問，可以加群進行討論或發送郵件給我，我會盡我所能為您解答，與君共勉！