1. SecondaryNameNode節點的主要功能是週期性將元數據節點的命名空間鏡像文件和修改日誌進行合併,以防日誌文件過大。node
2.NameNode的鏡像備份,若是NameNode宕機,能夠從SecondaryNameNode恢復數據,但會存在數據丟失的狀況(SecondaryNameNode最後一次讀取鏡像和修改日誌到宕機中間的數據丟失)分佈式
NameNode主要用來保存HDFS的元數據信息,好比命名空間信息、塊信息等。爲了保證效率,Namenode在啓動的時候會將這些信息加載到內存中;同時,也會將這些信息持久化到硬盤中,一般會造成如下文件:空間命名鏡像文件(fsimage)和修改日誌文件(edits)。下圖爲NameNode的文件目錄結構:oop
NameNode在啓動時,會讀取fsimage文件、合併edits文件。可是通常在集羣中,namenode不多會重啓,就致使了edits文件會逐漸變大,從而致使edits文件難以管理、重啓變慢、edits文件損壞丟失過多數據等各類問題。
post
因此,Hadoop使用SecondaryNameNode來合併fsimage和edits文件,減小NameNode的工做量,提升Hadoop集羣的可靠性。spa
SecondaryNameNode的工做流程以下:日誌
SecondaryNameNode節點通知NameNode節點生成新的日誌文件,之後的日誌都寫到新的日誌文件中。orm
SecondaryNameNode節點用http get從NameNode節點得到fsimage文件及舊的日誌文件。進程
SecondaryNameNode節點將fsimage文件加載到內存中,並執行日誌文件中的操做,而後生成新的fsimage文件。內存
SecondaryNameNode節點將新的fsimage文件用http post傳回NameNode節點上。get
NameNode節點能夠將舊的fsimage文件及舊的日誌文件,換爲新的fsimage文件和新的日誌文件(第一步生成的),而後更新fstime文件,寫入這次checkpoint的時間。
這樣NameNode節點中的fsimage文件保存了最新的checkpoint的元數據信息,日誌文件也從新開始,不會變的很大了。
Secondary NameNode的檢查點進程啓動,是由兩個配置參數控制的:
fs.checkpoint.period(新版本dfs.namenode.checkpoint.period),指定連續兩次檢查點的最大時間間隔, 默認值是1小時。
fs.checkpoint.size(新版本有變化,可是沒找到變成什麼了)定義了edits日誌文件的最大值,一旦超過這個值會致使強制執行檢查點(即便沒到檢查點的最大時間間隔)。默認值是64MB。
SecondaryNameNode運行在另一臺非NameNode的 機器上
SecondaryNameNode進程默認是運行在NameNode節點的機器上的,若是這臺機器出錯,宕機,對恢復HDFS文件系統是很大的災難,更好的方式是:將SecondaryNameNode的進程配置在另一臺機器 上運行。至於爲何要將SNN進程運行在一臺非NameNode的 機器上,這主要出於兩點考慮:
可擴展性: 建立一個新的HDFS的snapshot須要將namenode中load到內存的metadata信息所有拷貝一遍,這樣的操做須要的內存就須要 和namenode佔用的內存同樣,因爲分配給namenode進程的內存實際上是對HDFS文件系統的限制,若是分佈式文件系統很是的大,那麼namenode那臺機器的內存就可能會被namenode進程所有佔據。
容錯性: 當snn建立一個checkpoint的時候,它會將checkpoint拷貝成metadata的幾個拷貝。將這個操做運行到另一臺機器,還能夠提供分佈式文件系統的容錯性。