【轉】Hadoop 1.x中fsimage和edits合併實現

　　在NameNode運行期間，HDFS的全部更新操做都是直接寫到edits中，長此以往edits文件將會變得很大；雖然這對NameNode運行時候是沒有什麼影響的，可是咱們知道當NameNode重啓的時候，NameNode先將fsimage裏面的全部內容映像到內存中，而後再一條一條地執行edits中的記錄，當edits文件很是大的時候，會致使NameNode啓動操做很是地慢，而在這段時間內HDFS系統處於安全模式，這顯然不是用戶要求的。能不能在NameNode運行的時候使得edits文件變小一些呢？實際上是能夠的，本文主要是針對Hadoop 1.x版本，說明其是怎麼將edits和fsimage文件合併的，Hadoop 2.x版本edits和fsimage文件合併是不一樣的。
　　用過Hadoop的用戶應該都知道在Hadoop裏面有個SecondaryNamenode進程，從名字看來你們很容易將它看成NameNode的熱備進程。其實真實的狀況不是這樣的。SecondaryNamenode是HDFS架構中的一個組成部分，它是用來保存namenode中對HDFS metadata的信息的備份，並減小namenode重啓的時間而設定的！通常都是將SecondaryNamenode單獨運行在一臺機器上，那麼SecondaryNamenode是如何namenode重啓的時間的呢？來看看SecondaryNamenode的工做狀況：
　　（1）SecondaryNamenode會按期的和NameNode通訊，請求其中止使用edits文件，暫時將新的寫操做寫到一個新的文件edit.new上來，這個操做是瞬間完成，上層寫日誌的函數徹底感受不到差異；
　　（2）SecondaryNamenode經過HTTP GET方式從NameNode上獲取到fsimage和edits文件，並下載到本地的相應目錄下；
　　（3）SecondaryNamenode將下載下來的fsimage載入到內存，而後一條一條地執行edits文件中的各項更新操做，使得內存中的fsimage保存最新；這個過程就是edits和fsimage文件合併；
　　（4）SecondaryNamenode執行完（3）操做以後，會經過post方式將新的fsimage文件發送到NameNode節點上
　　（5）NameNode將從SecondaryNamenode接收到的新的fsimage替換舊的fsimage文件，同時將edit.new替換edits文件，經過這個過程edits就變小了！整個過程的執行能夠經過下面的圖說明：
　　在（1）步驟中，咱們談到SecondaryNamenode會按期的和NameNode通訊，這個是須要配置的,能夠經過core-site.xml進行配置，下面是默認的配置：

1 <property>
2   <name>fs.checkpoint.period</name>
3   <value>3600</value>
4   <description>The number of seconds between two periodic checkpoints.
5   </description>
6 </property>

 

　　其實若是當fs.checkpoint.period配置的時間尚未到期，咱們也能夠經過判斷當前的edits大小來觸發一次合併的操做，能夠經過下面配置

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

 

　　當edits文件大小超過以上配置，即便fs.checkpoint.period還沒到，也會進行一次合併。順便說說SecondaryNamenode下載下來的fsimage和edits暫時存放的路徑能夠經過下面的屬性進行配置：

 1 <property>
 2   <name>fs.checkpoint.dir</name>
 3   <value>${hadoop.tmp.dir}/dfs/namesecondary</value>
 4   <description>Determines where on the local filesystem the DFS secondary
 5       name node should store the temporary images to merge.
 6       If this is a comma-delimited list of directories then the image is
 7       replicated in all of the directories for redundancy.
 8   </description>
 9 </property>
10 
11 <property>
12   <name>fs.checkpoint.edits.dir</name>
13   <value>${fs.checkpoint.dir}</value>
14   <description>Determines where on the local filesystem the DFS secondary
15       name node should store the temporary edits to merge.
16       If this is a comma-delimited list of directoires then teh edits is
17       replicated in all of the directoires for redundancy.
18       Default value is same as fs.checkpoint.dir
19   </description>
20 </property>

 

　　從上面的描述咱們能夠看出，SecondaryNamenode根本就不是Namenode的一個熱備，其只是將fsimage和edits合併。其擁有的fsimage不是最新的，由於在他從NameNode下載fsimage和edits文件時候，新的更新操做已經寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的！固然，若是NameNode中的fsimage真的出問題了，仍是能夠用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage，雖然已經不是最新的fsimage，可是咱們能夠將損失減少到最少！
　　在Hadoop 2.x經過配置JournalNode來實現Hadoop的高可用性，這樣主被NameNode上的fsimage和edits都是最新的，任什麼時候候只要有一臺NameNode掛了，也可使得集羣中的fsimage是最新狀態！

 

轉載自： http://www.iteblog.com/archives/969