【轉】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 triggers5        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 secondary15       name node should store the temporary edits to merge.16       If this is a comma-delimited list of directoires then teh edits is17       replicated in all of the directoires for redundancy.18       Default value is same as fs.checkpoint.dir19   </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

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