fsimage和edits如何合并

這篇文章給大家分享的是有關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 1.x

用過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就變小了！整個過程的執行可以通過下面的圖說明：

從上面的描述我們可以看出，SecondaryNamenode根本就不是Namenode的一個熱備，其只是將fsimage和edits合并。其擁有的fsimage不是最新的，因為在他從NameNode下載fsimage和edits文件時候，新的更新操作已經寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的！當然，如果NameNode中的fsimage真的出問題了，還是可以用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage，雖然已經不是最新的fsimage，但是我們可以將損失減小到最少！

Hadoop 2.x

我們知道，在Hadoop 2.x中解決了NameNode的單點故障問題；同時SecondaryName已經不用了，而之前的Hadoop 1.x中是通過SecondaryName來合并fsimage和edits以此來減小edits文件的大小，從而減少NameNode重啟的時間。而在Hadoop 2.x中已經不用SecondaryName，那它是怎么來實現fsimage和edits合并的呢？首先我們得知道，在Hadoop 2.x中提供了HA機制（解決NameNode單點故障），可以通過配置奇數個JournalNode來實現HA，如何配置今天就不談了！HA機制通過在同一個集群中運行兩個NN（active NN & standby NN）來解決NameNode的單點故障，在任何時間，只有一臺機器處于Active狀態；另一臺機器是處于Standby狀態。Active NN負責集群中所有客戶端的操作；而Standby NN主要用于備用，它主要維持足夠的狀態，如果必要，可以提供快速的故障恢復。
　　為了讓Standby NN的狀態和Active NN保持同步，即元數據保持一致，它們都將會和JournalNodes守護進程通信。當Active NN執行任何有關命名空間的修改，它需要持久化到一半以上的JournalNodes上(通過edits log持久化存儲)，而Standby NN負責觀察edits log的變化，它能夠讀取從JNs中讀取edits信息，并更新其內部的命名空間。一旦Active NN出現故障，Standby NN將會保證從JNs中讀出了全部的Edits，然后切換成Active狀態。Standby NN讀取全部的edits可確保發生故障轉移之前，是和Active NN擁有完全同步的命名空間狀態

配置屬性

在hdfs-site.xml里配置以下屬性：

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
  <description>The number of seconds between two periodic checkpoints.
  </description>
</property>
 
<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60</value>
  <description>The SecondaryNameNode and CheckpointNode will poll the NameNode
  every 'dfs.namenode.checkpoint.check.period' seconds to query the number
  of uncheckpointed transactions.
  </description>
</property>

感謝各位的閱讀！關于“fsimage和edits如何合并”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！