NAMENODE工作機制

學習目標：理解namenode的工作機制尤其是元數據管理機制，以增強對HDFS工作原理的理解，及培養hadoop集群運營中“性能調優”、“namenode”故障問題的分析解決能力

?

問題場景：

1、集群啟動后，可以查看目錄，但是上傳文件時報錯，打開web頁面可看到namenode正處于safemode狀態，怎么處理？

解釋：

safemode是namenode的一種狀態（active/standby/safemode安全模式）

namenode進入安全模式的原理：

? a、namenode發現集群中的block丟失率達到一定比例時（0.01%），namenode就會進入安全模式，在安全模式下，客戶端不能對任何數據進行操作，只能查看元數據信息（比如ls/mkdir）

? b、如何退出安全模式？

找到問題所在，進行修復（比如修復宕機的datanode）

或者可以手動強行退出安全模式（沒有真正解決問題）： hdfs namenode--safemode leave

? c、在hdfs集群正常冷啟動時，namenode也會在safemode狀態下維持相當長的一段時間，此時你不需要去理會，等待它自動退出安全模式即可

(原理：

namenode的內存元數據中，包含文件路徑、副本數、blockid，及每一個block所在datanode的信息，而fsimage中，不包含block所在的datanode信息，那么，當namenode冷啟動時，此時內存中的元數據只能從fsimage中加載而來，從而就沒有block所在的datanode信息——>就會導致namenode認為所有的block都已經丟失——>進入安全模式——>datanode啟動后，會定期向namenode匯報自身所持有的blockid信息，——>隨著datanode陸續啟動，從而陸續匯報block信息，namenode就會將內存元數據中的block所在datanode信息補全更新——>找到了所有block的位置，從而自動退出安全模式)

?

2、Namenode服務器的磁盤故障導致namenode宕機，如何挽救集群及數據？

3、Namenode是否可以有多個？namenode內存要配置多大？namenode跟集群數據存儲能力有關系嗎？

4、文件的blocksize究竟調大好還是調小好？--結合mapreduce

……

?

諸如此類問題的回答，都需要基于對namenode自身的工作原理的深刻理解

?

5.1 NAMENODE職責

NAMENODE職責：

負責客戶端請求的響應

元數據的管理（查詢，修改）

5.2 元數據管理

namenode對數據的管理采用了三種存儲形式：

內存元數據(NameSystem)

磁盤元數據鏡像文件

數據操作日志文件（可通過日志運算出元數據）

5.2.1元數據存儲機制

A、內存中有一份完整的元數據(內存meta data)

B、磁盤有一個“準完整”的元數據鏡像（fsimage）文件(在namenode的工作目錄中)

C、用于銜接內存metadata和持久化元數據鏡像fsimage之間的操作日志（edits文件）注：當客戶端對hdfs中的文件進行新增或者修改操作，操作記錄首先被記入edits日志文件中，當客戶端操作成功后，相應的元數據會更新到內存meta.data中

5.2.2 元數據手動查看

可以通過hdfs的一個工具來查看edits中的信息

bin/hdfs oev -i edits -o edits.xml bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

5.2.3 元數據的checkpoint

每隔一段時間，會由secondarynamenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，并加載到內存進行merge（這個過程稱為checkpoint）

?

checkpoint的詳細過程

?

checkpoint操作的觸發條件配置參數

dfs.namenode.checkpoint.check.period=60? #檢查觸發條件是否滿足的頻率，60秒 dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary #以上兩個參數做checkpoint操作時，secondary namenode的本地工作目錄 dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir} ? dfs.namenode.checkpoint.max-retries=3? #最大重試次數 dfs.namenode.checkpoint.period=3600? #兩次checkpoint之間的時間間隔3600秒 dfs.namenode.checkpoint.txns=1000000 #兩次checkpoint之間最大的操作記錄

checkpoint的附帶作用

namenode和secondary namenode的工作目錄存儲結構完全相同，所以，當namenode故障退出需要重新恢復時，可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄，以恢復namenode的元數據

?

5.2.4 元數據目錄說明

在第一次部署好Hadoop集群的時候，我們需要在NameNode（NN）節點上格式化磁盤：

$HADOOP_HOME/bin/hdfs namenode -format

格式化完成之后，將會在$dfs.namenode.name.dir/current目錄下如下的文件結構

current/|-- VERSION|-- edits_*|-- fsimage_0000000000008547077|-- fsimage_0000000000008547077.md5`-- seen_txid

其中的dfs.name.dir是在hdfs-site.xml文件中配置的，默認值如下：

<property>? <name>dfs.name.dir</name>? <value>file://${hadoop.tmp.dir}/dfs/name</value></property>?hadoop.tmp.dir是在core-site.xml中配置的，默認值如下<property>? <name>hadoop.tmp.dir</name>? <value>/tmp/hadoop-${user.name}</value>? <description>A base for other temporary directories.</description></property>

?

dfs.namenode.name.dir屬性可以配置多個目錄，

如/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,....。各個目錄存儲的文件結構和內容都完全一樣，相當于備份，這樣做的好處是當其中一個目錄損壞了，也不會影響到Hadoop的元數據，特別是當其中一個目錄是NFS（網絡文件系統Network FileSystem，NFS）之上，即使你這臺機器損壞了，元數據也得到保存。
下面對$dfs.namenode.name.dir/current/目錄下的文件進行解釋。
1、VERSION文件是Java屬性文件，內容大致如下：

#Fri Nov 15 19:47:46 CST 2013namespaceID=934548976clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196cTime=0storageType=NAME_NODEblockpoolID=BP-893790215-192.168.24.72-1383809616115layoutVersion=-47

?

?

其中
　　（1）、namespaceID是文件系統的唯一標識符，在文件系統首次格式化之后生成的；
　　（2）、storageType說明這個文件存儲的是什么進程的數據結構信息（如果是DataNode，storageType=DATA_NODE）；
　　（3）、cTime表示NameNode存儲時間的創建時間，由于我的NameNode沒有更新過，所以這里的記錄值為0，以后對NameNode升級之后，cTime將會記錄更新時間戳；
　　（4）、layoutVersion表示HDFS永久性數據結構的版本信息， 只要數據結構變更，版本號也要遞減，此時的HDFS也需要升級，否則磁盤仍舊是使用舊版本的數據結構，這會導致新版本的NameNode無法使用；
　　（5）、clusterID是系統生成或手動指定的集群ID，在-clusterid選項中可以使用它；如下說明

?

a、使用如下命令格式化一個Namenode：

$HADOOP_HOME/bin/hdfs namenode -format [-clusterId<cluster_id>]

選擇一個唯一的cluster_id，并且這個cluster_id不能與環境中其他集群有沖突。如果沒有提供cluster_id，則會自動生成一個唯一的ClusterID。

b、使用如下命令格式化其他Namenode：

?$HADOOP_HOME/bin/hdfs namenode -format-clusterId <cluster_id>

c、升級集群至最新版本。在升級過程中需要提供一個ClusterID，例如：

$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config$HADOOP_CONF_DIR? -upgrade -clusterId <cluster_ID>

如果沒有提供ClusterID，則會自動生成一個ClusterID。

　　（6）、blockpoolID：是針對每一個Namespace所對應的blockpool的ID，上面的這個BP-893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的存儲塊池的ID，這個ID包括了其對應的NameNode節點的ip地址。
　　
2、$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾數，namenode重啟的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。所以當你的hdfs發生異常重啟的時候，一定要比對seen_txid內的數字是不是你edits最后的尾數，不然會發生建置namenode時metaData的資料有缺少，導致誤刪Datanode上多余Block的資訊。

?

3、$dfs.namenode.name.dir/current目錄下在format的同時也會生成fsimage和edits文件，及其對應的md5校驗文件。

?

?

補充：seen_txid

文件中記錄的是edits滾動的序號，每次重啟namenode時，namenode就知道要將哪些edits進行加載edits

?

?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的NAMENODE工作机制，元数据管理(元数据存储机制、元数据手动查看)、元数据的checkpoint、元数据目录说明（来自学习资料）的全部內容，希望文章能夠幫你解決所遇到的問題。

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