當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）

發布時間：2024/9/27 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了 Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

前言

最近剛接觸Hadoop, 一直沒有弄明白NameNode和Secondary NameNode的區別和關系。很多人都認為，Secondary NameNode是NameNode的備份，是為了防止NameNode的單點失敗的，直到讀了這篇文章Secondary Namenode - What it really do??(需翻墻)才發現并不是這樣。文章寫的很通俗易懂，現將其翻譯如下：

Secondary NameNode:它究竟有什么作用？

在Hadoop中，有一些命名不好的模塊，Secondary NameNode是其中之一。從它的名字上看，它給人的感覺就像是NameNode的備份。但它實際上卻不是。很多Hadoop的初學者都很疑惑，Secondary NameNode究竟是做什么的，而且它為什么會出現在HDFS中。因此，在這篇文章中，我想要解釋下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的備份。所以從現在起，讓我們養成一個習慣，稱呼它為檢查點節點吧。

后記

這篇文章基本上已經清楚的介紹了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工作原理

日志與鏡像的定期合并總共分五步：

SecondaryNameNode通知NameNode準備提交edits文件，此時主節點產生edits.new

SecondaryNameNode通過http get方式獲取NameNode的fsimage與edits文件（在SecondaryNameNode的current同級目錄下可見到 temp.check-point或者previous-checkpoint目錄，這些目錄中存儲著從namenode拷貝來的鏡像文件）

SecondaryNameNode開始合并獲取的上述兩個文件，產生一個新的fsimage文件fsimage.ckpt

SecondaryNameNode用http post方式發送fsimage.ckpt至NameNode

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為單獨節點時需要設置。

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。步驟如下：

準備原來機器一樣的機器，包括配置和文件

創建一個空的文件夾，該文件夾就是配置文件中dfs.name.dir所指向的文件夾。

拷貝你的secondary NameNode checkpoint出來的文件，到某個文件夾，該文件夾為fs.checkpoint.dir指向的文件夾（例如：/home/hadadm/clusterdir/tmp/dfs/namesecondary）

執行命令bin/hadoop namenode –importCheckpoint

這樣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可以解決這個問題

總結

以上是生活随笔為你收集整理的Secondary NameNode:它究竟有什么作用？（转自：http://blog.csdn.net/xh16319/article/details/31375197）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：东风悦达起亚多少钱探究起亚车型价格及性
下一篇：二手奥拓为什么那么贵？