這篇文章給大家分享的是有關(guān)fsimage和edits如何合并的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

成都創(chuàng)新互聯(lián)公司專注于瀏陽網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供瀏陽營銷型網(wǎng)站建設(shè)，瀏陽網(wǎng)站制作、瀏陽網(wǎng)頁設(shè)計、瀏陽網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)公司服務(wù)，打造瀏陽網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供瀏陽網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

在NameNode運行期間，HDFS的所有更新操作都是直接寫到edits中，久而久之edits文件將會變得很大；雖然這對NameNode運行時候是沒有什么影響的，但是我們知道當(dāng)NameNode重啟的時候，NameNode先將fsimage里面的所有內(nèi)容映像到內(nèi)存中，然后再一條一條地執(zhí)行edits中的記錄，當(dāng)edits文件非常大的時候，會導(dǎo)致NameNode啟動操作非常地慢，而在這段時間內(nèi)HDFS系統(tǒng)處于安全模式，這顯然不是用戶要求的。能不能在NameNode運行的時候使得edits文件變小一些呢？其實是可以的，本文主要是針對Hadoop 1.x版本，說明其是怎么將edits和fsimage文件合并的，Hadoop 2.x版本edits和fsimage文件合并是不同的。

Hadoop 1.x

用過Hadoop的用戶應(yīng)該都知道在Hadoop里面有個SecondaryNamenode進(jìn)程，從名字看來大家很容易將它當(dāng)作NameNode的熱備進(jìn)程。其實真實的情況不是這樣的。SecondaryNamenode是HDFS架構(gòu)中的一個組成部分，它是用來保存namenode中對HDFS metadata的信息的備份，并減少namenode重啟的時間而設(shè)定的！一般都是將SecondaryNamenode單獨運行在一臺機(jī)器上，那么SecondaryNamenode是如何namenode重啟的時間的呢？來看看SecondaryNamenode的工作情況：
（1）、SecondaryNamenode會定期的和NameNode通信，請求其停止使用edits文件，暫時將新的寫操作寫到一個新的文件edit.new上來，這個操作是瞬間完成，上層寫日志的函數(shù)完全感覺不到差別；
（2）、SecondaryNamenode通過HTTP GET方式從NameNode上獲取到fsimage和edits文件，并下載到本地的相應(yīng)目錄下；
（3）、SecondaryNamenode將下載下來的fsimage載入到內(nèi)存，然后一條一條地執(zhí)行edits文件中的各項更新操作，使得內(nèi)存中的fsimage保存最新；這個過程就是edits和fsimage文件合并；
（4）、SecondaryNamenode執(zhí)行完（3）操作之后，會通過post方式將新的fsimage文件發(fā)送到NameNode節(jié)點上
（5）、NameNode將從SecondaryNamenode接收到的新的fsimage替換舊的fsimage文件，同時將edit.new替換edits文件，通過這個過程edits就變小了！整個過程的執(zhí)行可以通過下面的圖說明：

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

Hadoop 2.x

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

配置屬性

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

  dfs.namenode.checkpoint.period
  3600
  The number of seconds between two periodic checkpoints.
  

 

  dfs.namenode.checkpoint.check.period
  60
  The SecondaryNameNode and CheckpointNode will poll the NameNode
  every 'dfs.namenode.checkpoint.check.period' seconds to query the number
  of uncheckpointed transactions.
  

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