Secondary NameNode 的做用

https://blog.csdn.net/xh16319/article/details/31375197

不少人都認爲，Secondary NameNode是NameNode的備份，是爲了防止NameNode的單點失敗的，其實並非這樣。

Secondary NameNode:它究竟有什麼做用？

在Hadoop中，有一些命名很差的模塊，Secondary NameNode是其中之一。從它的名字上看，它給人的感受就像是NameNode的備份。但它實際上卻不是。不少Hadoop的初學者都很疑惑，Secondary NameNode到底是作什麼的，並且它爲何會出如今HDFS中。所以，在這篇文章中，我想要解釋下Secondary NameNode在HDFS中所扮演的角色。

從它的名字來看，你可能認爲它跟NameNode有點關係。沒錯，你猜對了。所以在咱們深刻了解Secondary NameNode以前，咱們先來看看NameNode是作什麼的。

NameNode

NameNode主要是用來保存HDFS的元數據信息，好比命名空間信息，塊信息等。當它運行的時候，這些信息是存在內存中的。可是這些信息也能夠持久化到磁盤上。

上面的這張圖片展現了NameNode怎麼把元數據保存到磁盤上的。這裏有兩個不一樣的文件：

1. fsimage - 它是在NameNode啓動時對整個文件系統的快照
2. edit logs - 它是在NameNode啓動後，對文件系統的改動序列

只有在NameNode重啓時，edit logs纔會合併到fsimage文件中，從而獲得一個文件系統的最新快照。可是在產品集羣中NameNode是不多重啓的，這也意味着當NameNode運行了很長時間後，edit logs文件會變得很大。在這種狀況下就會出現下面一些問題：

1. edit logs文件會變的很大，怎麼去管理這個文件是一個挑戰。
2. NameNode的重啓會花費很長時間，由於有不少改動[筆者注:在edit logs中]要合併到fsimage文件上。
3. 若是NameNode掛掉了，那咱們就丟失了不少改動由於此時的fsimage文件很是舊。[筆者注: 筆者認爲在這個狀況下丟失的改動不會不少, 由於丟失的改動應該是還在內存中可是沒有寫到edit logs的這部分。]

所以爲了克服這個問題，咱們須要一個易於管理的機制來幫助咱們減少edit logs文件的大小和獲得一個最新的fsimage文件，這樣也會減少在NameNode上的壓力。這跟Windows的恢復點是很是像的，Windows的恢復點機制容許咱們對OS進行快照，這樣當系統發生問題時，咱們可以回滾到最新的一次恢復點上。

如今咱們明白了NameNode的功能和所面臨的挑戰 - 保持文件系統最新的元數據。那麼，這些跟Secondary NameNode又有什麼關係呢？

Secondary NameNode

SecondaryNameNode就是來幫助解決上述問題的，它的職責是合併NameNode的edit logs到fsimage文件中。

上面的圖片展現了Secondary NameNode是怎麼工做的。

1. 首先，它定時到NameNode去獲取edit logs，並更新到fsimage上。[筆者注：Secondary NameNode本身的fsimage]
2. 一旦它有了新的fsimage文件，它將其拷貝回NameNode中。
3. NameNode在下次重啓時會使用這個新的fsimage文件，從而減小重啓的時間。

Secondary NameNode的整個目的是在HDFS中提供一個檢查點。它只是NameNode的一個助手節點。這也是它在社區內被認爲是檢查點節點的緣由。

如今，咱們明白了Secondary NameNode所作的不過是在文件系統中設置一個檢查點來幫助NameNode更好的工做。它不是要取代掉NameNode也不是NameNode的備份。因此從如今起，讓咱們養成一個習慣，稱呼它爲檢查點節點吧。

 

後記

這篇文章基本上已經清楚的介紹了Secondary NameNode的工做以及爲何要這麼作。最後補充一點細節，是關於NameNode是何時將改動寫到edit logs中的？這個操做其實是由DataNode的寫操做觸發的，當咱們往DataNode寫文件時，DataNode會跟NameNode通訊，告訴NameNode什麼文件的第幾個block放在它那裏，NameNode這個時候會將這些元數據信息寫到edit logs文件中。

 

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hadoop Namenode和Secondary Namenode

Secondarynamenode做用

SecondaryNameNode有兩個做用，一是鏡像備份，二是日誌與鏡像的按期合併。兩個過程同時進行，稱爲checkpoint. 鏡像備份的做用:備份fsimage(fsimage是元數據發送檢查點時寫入文件);日誌與鏡像的按期合併的做用:將Namenode中edits日誌和fsimage合併,防止(若是Namenode節點故障，namenode下次啓動的時候，會把fsimage加載到內存中，應用edit log,edit log每每很大，致使操做每每很耗時。)

Secondarynamenode工做原理

日誌與鏡像的按期合併總共分五步：

1. SecondaryNameNode通知NameNode準備提交edits文件，此時主節點產生edits.new
2. SecondaryNameNode經過http get方式獲取NameNode的fsimage與edits文件（在SecondaryNameNode的current同級目錄下可見到 temp.check-point或者previous-checkpoint目錄，這些目錄中存儲着從namenode拷貝來的鏡像文件）
3. SecondaryNameNode開始合併獲取的上述兩個文件，產生一個新的fsimage文件fsimage.ckpt
4. SecondaryNameNode用http post方式發送fsimage.ckpt至NameNode
5. NameNode將fsimage.ckpt與edits.new文件分別重命名爲fsimage與edits，而後更新fstime，整個checkpoint過程到此結束。 在新版本的hadoop中（hadoop0.21.0）,SecondaryNameNode兩個做用被兩個節點替換， checkpoint node與backup node. SecondaryNameNode備份由三個參數控制fs.checkpoint.period控制週期，fs.checkpoint.size控制日誌文件超過多少大小時合併， dfs.http.address表示http地址，這個參數在SecondaryNameNode爲單獨節點時須要設置。

相關配置文件

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

<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>

鏡像備份的週期時間是能夠修改的，若是不想一個小時備份一次，能夠改的時間短點。core-site.xml中的fs.checkpoint.period值

Secondarynamenode工做原理圖

這也解釋了下面的問題：

(1)、爲何namenode和Secondary namenode須要一樣大內存

(2)、大集羣中namenode和Secondary namenode須要是各自獨立的兩個節點。

Checkpoint的日誌信息

2011-07-19 23:59:28,435 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 02011-07-19 23:59:28,472 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file fsimage size 548 bytes. 2011-07-19 23:59:28,473 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file edits size 631 bytes. 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: fsOwner=hadadm,hadgrp 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: supergroup=supergroup 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: isPermissionEnabled=true 2011-07-19 23:59:28,488 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files = 6 2011-07-19 23:59:28,489 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files under construction = 0 2011-07-19 23:59:28,490 INFO org.apache.hadoop.hdfs.server.common.Storage: Edits file /home/hadadm/clusterdir/tmp/dfs/namesecondary/current/edits of size 631 edits # 6 loaded in 0 seconds. 2011-07-19 23:59:28,493 INFO org.apache.hadoop.hdfs.server.common.Storage: Image file of size 831 saved in 0 seconds. 2011-07-19 23:59:28,513 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0 2011-07-19 23:59:28,543 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Posted URL master:50070putimage=1&port=50090&machine=10.253.74.234&token=-18:1766583108:0:1311091168000:1311087567797 2011-07-19 23:59:28,561 WARN org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Checkpoint done. New Image Size: 831

 Namenode/Secondarynamenode文件結構

[hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary/current]$ ll 總用量 24 drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 ./ drwxr-xr-x  5 hadadm hadgrp 4096  7月 19 23:59 ../ -rw-r–r–  1 hadadm hadgrp    4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp  548  7月 19 22:59 fsimage -rw-r–r–  1 hadadm hadgrp    8  7月 19 22:59 fstime -rw-r–r–  1 hadadm hadgrp  101  7月 19 22:59 VERSION   [hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary/current] $ cat VERSION #Tue Jul 19 22:59:27 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 推這裏VERSION表示的是secondarynamenode中的fsimage版本是22:59時的;加上edits應用的日誌就能夠到23:59

[hadadm@master /home/hadadm/clusterdir/dfs/name/current]$ ls -l 總用量 16 -rw-r–r–  1 hadadm hadgrp   4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp 831  7月 19 23:59 fsimage -rw-r–r–  1 hadadm hadgrp   8  7月 19 23:59 fstime -rw-r–r–  1 hadadm hadgrp 101  7月 19 23:59 VERSION   [hadadm@master /home/hadadm/clusterdir/dfs/name/current] $ cat VERSION #Tue Jul 19 23:59:28 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 這裏VERSION表示的是namenode中的fsimage版本是23:59時的; edits應用沒有變動 這裏的fsimage至關於secondarynamenode裏面的fsimage+edits

[hadadm@slave /home/hadadm/clusterdir/tmp/dfs/namesecondary]$ ls -l 總用量 12 drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 23:59 current drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 image -rw-r–r–  1 hadadm hadgrp    0  7月 19 23:59 in_use.lock drwxr-xr-x  2 hadadm hadgrp 4096  7月 19 22:59 previous.checkpoint   [hadadm@slavea /home/hadadm/clusterdir/tmp/dfs/namesecondary] $ ls -l previous.checkpoint/ 總用量 16 -rw-r–r–  1 hadadm hadgrp   4  7月 19 23:59 edits -rw-r–r–  1 hadadm hadgrp 548  7月 19 22:59 fsimage -rw-r–r–  1 hadadm hadgrp   8  7月 19 22:59 fstime -rw-r–r–  1 hadadm hadgrp 101  7月 19 22:59 VERSION 這裏上一個檢查點的數據是能夠用來恢復數據的

Import Checkpoint（恢復數據）

若是主節點namenode掛掉了，硬盤數據須要時間恢復或者不能恢復了，如今又想馬上恢復HDFS，這個時候就能夠import checkpoint。步驟以下：

1. 準備原來機器同樣的機器，包括配置和文件
2. 建立一個空的文件夾，該文件夾就是配置文件中dfs.name.dir所指向的文件夾。
3. 拷貝你的secondary NameNode checkpoint出來的文件，到某個文件夾，該文件夾爲fs.checkpoint.dir指向的文件夾（例如：/home/hadadm/clusterdir/tmp/dfs/namesecondary）
4. 執行命令bin/hadoop namenode –importCheckpoint
5. 這樣NameNode會讀取checkpoint文件，保存到dfs.name.dir。可是若是你的dfs.name.dir包含合法的 fsimage，是會執行失敗的。由於NameNode會檢查fs.checkpoint.dir目錄下鏡像的一致性，可是不會去改動它。

通常建議給maste配置多臺機器，讓namesecondary與namenode不在同一臺機器上值得推薦的是，你要注意備份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。

後續版本中的backupnode

Checkpoint Node 和 Backup Node在後續版本中hadoop-0.21.0，還提供了另外的方法來作checkpoint：Checkpoint Node 和 Backup Node。則兩種方式要比secondary NameNode好不少。因此 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node. Checkpoint Node像是secondary NameNode的改進替代版，Backup Node提供更大的便利，這裏就再也不介紹了。

BackupNode ： 備份結點。這個結點的模式有點像 mysql 中的主從結點複製功能， NN 能夠實時的將日誌傳送給 BN ，而 SNN 是每隔一段時間去 NN 下載 fsimage 和 edits 文件，而 BN 是實時的獲得操做日誌，而後將操做合併到 fsimage 裏。在 NN 裏提供了二個日誌流接口： EditLogOutputStream 和 EditLogInputStream 。即當 NN 有日誌時，不只會寫一份到本地 edits 的日誌文件，同時會向 BN 的網絡流中寫一份，當流緩衝達到閥值時，將會寫入到 BN 結點上， BN 收到後就會進行合併操做，這樣來完成低延遲的日誌複製功能。 總結： 當前的備份結點都是冷備份，因此還須要實現熱備份，使得 NN 掛了後，從結點自動的升爲主結點來提供服務。 主 NN 的效率問題： NN 的文件過多致使內存消耗問題， NN 中文件鎖問題， NN 的啓動時間。

由於Secondarynamenaode不是實施備份和同步,因此SNN會丟掉當前namenode的edit log數據,應該來講backupnode能夠解決這個問題