在Hadoop中，有一些命名不好的模塊，Secondary NameNode是其中之一。從它的名字上看，它給人的感覺就像是NameNode的備份。但它實際上卻不是。很多Hadoop的初學者都很疑惑，Secondary NameNode究竟是做什么的，而且它為什么會出現在HDFS中。
從它的名字來看，你可能認為它跟NameNode有點關系。沒錯，你猜對了。因此在我們深入了解Secondary NameNode之前，我們先來看看NameNode是做什么的。
NameNode
NameNode主要是用來保存HDFS的元數據信息，比如命名空間信息，塊信息等。當它運行的時候，這些信息是存在內存中的。但是這些信息也可以持久化到磁盤上。
上面的這張圖片展示了NameNode怎么把元數據保存到磁盤上的。這里有兩個不同的文件：
- fsimage - 它是在NameNode啟動時對整個文件系統的快照
- edit logs - 它是在NameNode啟動后，對文件系統的改動序列
只有在NameNode重啟時，edit logs才會合並到fsimage文件中，從而得到一個文件系統的最新快照。但是在產品集群中NameNode是很少重啟的，這也意味着當NameNode運行了很長時間后，edit logs文件會變得很大。在這種情況下就會出現下面一些問題：
- edit logs文件會變的很大，怎么去管理這個文件是一個挑戰。
- NameNode的重啟會花費很長時間，因為有很多改動[筆者注:在edit logs中]要合並到fsimage文件上。
- 如果NameNode掛掉了，那我們就丟失了很多改動因為此時的fsimage文件非常舊。[筆者注: 筆者認為在這個情況下丟失的改動不會很多, 因為丟失的改動應該是還在內存中但是沒有寫到edit logs的這部分。]
因此為了克服這個問題，我們需要一個易於管理的機制來幫助我們減小edit logs文件的大小和得到一個最新的fsimage文件，這樣也會減小在NameNode上的壓力。這跟Windows的恢復點是非常像的，Windows的恢復點機制允許我們對OS進行快照，這樣當系統發生問題時，我們能夠回滾到最新的一次恢復點上。
現在我們明白了NameNode的功能和所面臨的挑戰 - 保持文件系統最新的元數據。那么，這些跟Secondary NameNode又有什么關系呢？
Secondary NameNode
SecondaryNameNode就是來幫助解決上述問題的，它的職責是合並NameNode的edit logs到fsimage文件中。
上面的圖片展示了Secondary NameNode是怎么工作的。
- 首先，它定時到NameNode去獲取edit logs，並更新到fsimage上。[筆者注：Secondary NameNode自己的fsimage]
- 一旦它有了新的fsimage文件，它將其拷貝回NameNode中。
- NameNode在下次重啟時會使用這個新的fsimage文件，從而減少重啟的時間。
Secondary NameNode的整個目的是在HDFS中提供一個檢查點。它只是NameNode的一個助手節點。這也是它在社區內被認為是檢查點節點的原因。
現在，我們明白了Secondary NameNode所做的不過是在文件系統中設置一個檢查點來幫助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的備份。所以從現在起，讓我們養成一個習慣，稱呼它為檢查點節點吧。
后記
關於NameNode是什么時候將改動寫到edit logs中的？
這個操作實際上是由DataNode的寫操作觸發的，當我們往DataNode寫文件時，DataNode會跟NameNode通信，告訴NameNode什么文件的第幾個block放在它那里，NameNode這個時候會將這些元數據信息寫到edit logs文件中。