hadoop管理NameNode AND SecondaryNameNode

光從字面上來理解，很容易讓一些初學者先入爲主的認爲：SecondaryNameNode（snn）就是NameNode（nn）的熱備進程。其實不是。snn是HDFS架構中的一個組成部分，但是經常由於名字而被人誤解它真正的用途，其實它真正的用途，是用來保存namenode中對HDFS metadata的信息的備份，並減少namenode重啓的時間。對於hadoop進程中 ，要配置好並正確的使用 snn，還是需要做一些工作的。hadoop的默認配置中讓 snn進程默認運行在了 namenode 的那臺機器上，但是這樣的話，如果這臺機器出錯，宕機，對恢復HDFS文件系統是很大的災難，更好的方式是：將snn的進程配置在另外一臺機器 上運行。

在hadoop中，namenode負責對HDFS的metadata的持久化存儲，並且處理來自客戶端的對HDFS的各種操作的交互反饋。爲了保證交互速度，HDFS文件系統的metadata是被load到namenode機器的內存中的，並且會將內存中的這些數據保存到磁盤進行持久化存儲。爲了保證這個持久化過程不會成爲HDFS操作的瓶頸，hadoop採取的方式是：沒有對任何一次的當前文件系統的snapshot進行持久化，對HDFS最近一段時間的操作list會被保存到namenode中的一個叫Editlog的文件中去。當重啓namenode時，除了 load fsImage意外，還會對這個EditLog文件中 記錄的HDFS操作進行replay，以恢復HDFS重啓之前的最終狀態。

而SecondaryNameNode，會週期性的將EditLog中記錄的對HDFS的操作合併到一個checkpoint中，然後清空EditLog。所以namenode的重啓就會Load最新的一個checkpoint，並replay EditLog中 記錄的hdfs操作，由於EditLog中記錄的是從 上一次checkpoint以後到現在的操作列表，所以就會比較小。如果沒有snn的這個週期性的合併過程，那麼當每次重啓namenode的時候，就會花費很長的時間。而這樣週期性的合併就能減少重啓的時間。同時也能保證HDFS系統的完整性。

這就是SecondaryNameNode所做的事情。所以snn並不能分擔namenode上對HDFS交互性操作的壓力。儘管如此，當namenode機器宕機或者namenode進程出問題時，namenode的daemon進程可以通過人工的方式從snn上拷貝一份metadata來恢復HDFS文件系統。

至於爲什麼要將SNN進程運行在一臺非NameNode的 機器上，這主要出於兩點考慮：

1. 可擴展性： 創建一個新的HDFS的snapshot需要將namenode中load到內存的metadata信息全部拷貝一遍，這樣的操作需要的內存就需要 和namenode佔用的內存一樣，由於分配給namenode進程的內存其實是對HDFS文件系統的限制，如果分佈式文件系統非常的大，那麼namenode那臺機器的內存就可能會被namenode進程全部佔據。
2. 容錯性： 當snn創建一個checkpoint的時候，它會將checkpoint拷貝成metadata的幾個拷貝。將這個操作運行到另外一臺機器，還可以提供分佈式文件系統的容錯性。

配置將SecondaryNameNode運行在另外一臺機器上

HDFS的一次運行實例是通過在namenode機器上的$HADOOP_HOME/bin/start-dfs.sh（或者start-all.sh） 腳本來啓動的。這個腳本會在運行該腳本的機器上啓動 namenode進程，而slaves機器上都會啓動DataNode進程，slave機器的列表保存在conf/slaves文件中，一行一臺機器。並且會在另外一臺機器上啓動一個snn進程，這臺機器由conf/masters文件指定。所以，這裏需要嚴格注意， conf/masters 文件中指定的機器，並不是說jobtracker或者namenode進程要 運行在這臺機器上，因爲這些進程是運行在 launch bin/start-dfs.sh或者 bin/start-mapred.sh(start-all.sh)的機器上的。所以，masters這個文件名是非常的令人混淆的，應該叫做secondaries會比較合適。然後，通過以下步驟：

1. 將所有想要運行secondarynamenode進程的機器寫到masters文件中，一行一臺。
2. 修改在masters文件中配置了的機器上的conf/hadoop-site.xml文件，加上如下選項：
   

<span style="font-size: small;"><property>
<name>dfs.http.address</name>
<value>namenode.hadoop-host.com:50070</value>
</property>
</span>

 

      core-site.xml：這裏有2個參數可配置，但一般來說我們不做修改。fs.checkpoint.period表示多長時間記錄一次hdfs的鏡像。默認是1小時。fs.checkpoint.size表示一次記錄多大的size，默認64M。

    

<span style="font-size: small;"><property>
  <name>fs.checkpoint.period</name>
  <value>3600</value>
  <description>The number of seconds between two periodic checkpoints.
  </description>
</property>

<property>
  <name>fs.checkpoint.size</name>
  <value>67108864</value>
  <description>The size of the current edit log (in bytes) that triggers
       a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
  </description>
</property>
</span>

 

3、配置檢查。配置完成之後，我們需要檢查一下是否成功。我們可以通過查看運行secondarynamenode的機器上文件目錄來確定是否成功配置。首先輸入jps查看是否存在secondarynamenode進程。如果存在，在查看對應的目錄下是否有備份記錄。如下圖：

該目錄一般存在於hadoop.tmp.dir/dfs/namesecondary/下面。

四、恢復

1、配置完成了，如何恢復。首先我們kill掉namenode進程，然後將hadoop.tmp.dir目錄下的數據刪除掉。製造master掛掉情況。

2、在配置參數dfs.name.dir指定的位置建立一個空文件夾； 把檢查點目錄的位置賦值給配置參數fs.checkpoint.dir； 啓動NameNode，並加上-importCheckpoint。（這句話抄襲的是hadoop-0.20.2/hadoop-0.20.2/docs/cn/hdfs_user_guide.html#Secondary+NameNode，看看文檔，有說明）

3、啓動namenode的時候採用hadoop namenode –importCheckpoint

五、總結

1、secondarynamenode可以配置多個，master文件裏面多寫幾個就可以。

2、千萬記得如果要恢復數據是需要手動拷貝到namenode機器上的。不是自動的（參看上面寫的恢復操作）。

3、鏡像備份的週期時間是可以修改的，如果不想一個小時備份一次，可以改的時間短點。core-site.xml中的fs.checkpoint.period值

 

轉：http://a280606790.iteye.com/blog/870123