這篇文章主要介紹了集群JournalNode服務(wù)重啟導(dǎo)致NameNode掛掉的示例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

成都創(chuàng)新互聯(lián)公司是一家專業(yè)的成都網(wǎng)站建設(shè)公司，我們專注網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)絡(luò)營(yíng)銷、企業(yè)網(wǎng)站建設(shè)，外鏈，1元廣告為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結(jié)構(gòu)的規(guī)劃UI設(shè)計(jì)到用戶體驗(yàn)提高，創(chuàng)新互聯(lián)力求做到盡善盡美。

1.問題描述

在我們的集群中修改了JournalNode服務(wù)的配置后需要重啟時(shí)配置生效，在進(jìn)行重啟操作時(shí)導(dǎo)致NameNode服務(wù)掛掉，具體操作步驟如下：

1.選擇sgpd229-013節(jié)點(diǎn)的JournalNode服務(wù)重啟

2.在sgpd229-013節(jié)點(diǎn)的JournalNode服務(wù)啟動(dòng)成功后，重啟剩余兩個(gè)節(jié)點(diǎn)的JN服務(wù)

3.重啟成功剩余兩個(gè)節(jié)點(diǎn)的JournalNode服務(wù)后，CM界面報(bào)NameNode服務(wù)異常退出

4.所有JournalNode服務(wù)正常啟動(dòng)后，重啟NameNode服務(wù)，故障恢復(fù)

2.異常分析

1.在2018-07-26 09:55:19分重啟sgpd229-013節(jié)點(diǎn)的JournalNode服務(wù)

2.重啟成功后，NameNode的異常日志如下，此時(shí)NameNode的服務(wù)均正常

通過NN服務(wù)的日志可以看到此時(shí)sgpd229-013節(jié)點(diǎn)的NN服務(wù)無法連接sgpd229-013節(jié)點(diǎn)的JN服務(wù)，但NN服務(wù)任然正常運(yùn)行，因?yàn)閟gpd229-012和sgpd229-014節(jié)點(diǎn)的JN服務(wù)正常。

3.待sgpd229-013節(jié)點(diǎn)的JN服務(wù)正常后，接著在CM上同時(shí)重啟sgpd229-012和sgpd229-014節(jié)點(diǎn)的JN服務(wù)

重啟成功后，此時(shí)sgpd229-012節(jié)點(diǎn)的NameNode服務(wù)異常退出，異常日志如下：

通過日志可以看到NN顯示無法連接sgpd229-012和sgpd229-014節(jié)點(diǎn)的JN服務(wù)，此時(shí)NN服務(wù)判斷JN服務(wù)不可用，直接SHUTDOWN，導(dǎo)致NameNode服務(wù)異常退出。

3.總結(jié)

1.在高可用的Hadoop集群中，JN服務(wù)至少要有兩個(gè)在正常運(yùn)行，否則會(huì)導(dǎo)致NameNode服務(wù)異常退出。在Fayson的這個(gè)異常分析中就出現(xiàn)了同時(shí)重啟兩個(gè)JN服務(wù)從而導(dǎo)致NameNode服務(wù)異常退出。

2.在啟用HDFS的HA時(shí)，部署JN服務(wù)時(shí)不能少于3個(gè)。

3.在集群中需要注意重啟JN服務(wù)時(shí)，則需要確保JN集群至少有兩個(gè)服務(wù)正常運(yùn)行，建議通過CM的滾動(dòng)重啟來完成。

關(guān)于QJM的設(shè)計(jì)及實(shí)現(xiàn)過程，F(xiàn)ayson摘自網(wǎng)上，供大家參考：

實(shí)現(xiàn)過程：

(1)初始化后，Active把editlog日志寫到2N+1上JN上，每個(gè)editlog有一個(gè)編號(hào)，每次寫editlog只要其中大多數(shù)JN返回成功（即大于等于N+1）即認(rèn)定寫成功。

(2)Standby定期從JN讀取一批editlog，并應(yīng)用到內(nèi)存中的FsImage中。

(3)如何fencing： NameNode每次寫Editlog都需要傳遞一個(gè)編號(hào)Epoch給JN，JN會(huì)對(duì)比Epoch，如果比自己保存的Epoch大或相同，則可以寫，JN更新自己的Epoch到最新，否則拒絕操作。在切換時(shí)，Standby轉(zhuǎn)換為Active時(shí)，會(huì)把Epoch+1，這樣就防止即使之前的NameNode向JN寫日志，也會(huì)失敗。

(4)寫日志：

  (a) NN通過RPC向N個(gè)JN異步寫Editlog，當(dāng)有N/2+1個(gè)寫成功，則本次寫成功。

  (b) 寫失敗的JN下次不再寫，直到調(diào)用滾動(dòng)日志操作，若此時(shí)JN恢復(fù)正常，則繼續(xù)向其寫日志。

  (c) 每條editlog都有一個(gè)編號(hào)txid，NN寫日志要保證txid是連續(xù)的，JN在接收寫日志時(shí)，會(huì)檢查txid是否與上次連續(xù)，否則寫失敗。

(5)讀日志：

(a) 定期遍歷所有JN，獲取未消化的editlog，按照txid排序。

(b) 根據(jù)txid消化editlog。

(6)切換時(shí)日志恢復(fù)機(jī)制

(a) 主從切換時(shí)觸發(fā)

(b) 準(zhǔn)備恢復(fù)（prepareRecovery），standby向JN發(fā)送RPC請(qǐng)求，獲取txid信息，并對(duì)選出最好的JN。

(c) 接受恢復(fù)（acceptRecovery），standby向JN發(fā)送RPC，JN之間同步Editlog日志。

(d) Finalized日志。即關(guān)閉當(dāng)前editlog輸出流時(shí)或滾動(dòng)日志時(shí)的操作。

(e) Standby同步editlog到最新

(7)如何選取最好的JN

  (a) 有Finalized的不用in-progress

  (b) 多個(gè)Finalized的需要判斷txid是否相等

  (c) 沒有Finalized的首先看誰的epoch更大

  (d) Epoch一樣則選txid大的。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“集群JournalNode服務(wù)重啟導(dǎo)致NameNode掛掉的示例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來學(xué)習(xí)!