應(yīng)了一個國內(nèi)某電信運營商集群恢復(fù)的事，集群故障很嚴重，做了HA的集群Namenode掛掉了。具體過程不詳，但是從受害者的只言片語中大概回顧一下歷史的片段。

創(chuàng)新互聯(lián)專注于霍城企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,成都商城網(wǎng)站開發(fā)?；舫蔷W(wǎng)站建設(shè)公司,為霍城等地區(qū)提供建站服務(wù)。全流程按需搭建網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

1. Active的namenode元數(shù)據(jù)硬盤滿了，滿了，滿了...上來第一句話就如雷貫耳。

2. 運維人員發(fā)現(xiàn)硬盤滿了以后執(zhí)行了對active namenode的元數(shù)據(jù)日志執(zhí)行了 echo "" > edit_xxxx-xxxx...第二句話如五雷轟頂。

3. 然后發(fā)現(xiàn)standby沒法切換，切換也沒用，因為standby的元數(shù)據(jù)和日志是5月份的...這個結(jié)果讓人無法直視。

因為周末要去外地講課，所以無法去在外地的現(xiàn)場，七夕加七八兩天用qq遠程協(xié)助的方式上去看了一下。幾個大問題累積下來，導致了最終悲劇的發(fā)生。

1. Namenode的元數(shù)據(jù)只保存在一個硬盤mount里，且該盤空間很小。又有N多人往里面塞了各種亂七八糟的文件，什么jar包，tar包，shell腳本。

2. 按照描述，standby元數(shù)據(jù)只有到5月份，說明standby要么掛了，要么壓根就沒啟動。

3. 沒有做ZKFC，就是失效自動恢復(fù)，應(yīng)該是采用的手動恢復(fù)方式（而且實際是沒有JournalNode的，后面再說）。

4. 至于raid0, lvm這種問題就完全忽略了，雖然這也是很大的問題。

然后他們自己折騰了一天，沒任何結(jié)果，實在起不來了，最好的結(jié)果是啟動兩臺standby namenode，無法切換active。通過關(guān)系找到了我，希望采用有償服務(wù)的方式讓我?guī)兔M行恢復(fù)。我一開始以為比較簡單，就答應(yīng)了。結(jié)果上去一看，故障的復(fù)雜程度遠超想象，堪稱目前遇到的最難的集群數(shù)據(jù)恢復(fù)挑戰(zhàn)。由于無法確切獲知他們自己操作后都發(fā)生了什么，他們自己也說不清楚，也或者迫于壓力不敢說，我只能按現(xiàn)有的數(shù)據(jù)資料嘗試進行恢復(fù)。

第一次嘗試恢復(fù)，我太小看他們的破壞力了，以至于第一次恢復(fù)是不成功的，七夕下班拋家舍業(yè)的開搞。在這次嘗試中，發(fā)現(xiàn)HA是沒有用ZKFC做自動恢復(fù)的，完全是手動恢復(fù)，于是順帶幫他們安裝配置了ZKFC。然后首先初始化shareEdits，發(fā)現(xiàn)他們壓根沒有做shareEdits，那就意味著，其實原來的JournalNode可能根本就沒起作用。然后啟動zookeeper，接著啟動journalnode，然后啟動兩個NN，兩個NN的狀態(tài)就是standby，然后啟動ZKFC，自動切換失敗。根據(jù)日志判斷，是兩個NN中的元數(shù)據(jù)不一致導致了腦裂。于是使用haadmin里面的隱藏命令強行指定了一個NN。啟動了一臺NN，而另一臺則在做腦裂后的元數(shù)據(jù)自動恢復(fù)。自動恢復(fù)log日志如下

INFO org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: replaying edit log: xxxx/xxxx transactions completed. (77%)

經(jīng)過漫長的等待，SNN元數(shù)據(jù)恢復(fù)了。但是一直沒有脫離safemode狀態(tài)，因為太晚了，就沒有繼續(xù)進行，只是告訴他們，等到safemode脫離了，就可以了，如果一直沒有脫離，就強行使用safemode leave脫離。但是，我把一切看的太簡單了。

第二天，打電話說集群仍然不能用。我上去一看，還是處于safemode。于是強行脫離safemode，但是只有active脫離了，standby仍未脫離，HDFS也無法寫入數(shù)據(jù)，這時看hdfs的web ui，active和standby的數(shù)據(jù)塊上報遠未達到需要的數(shù)量，意識到元數(shù)據(jù)有丟失。但對方堅稱元數(shù)據(jù)是故障后立刻備份的，而且當時的誤操作只是針對edits日志，fsp_w_picpath沒有動。說實話，我倒寧可他們把fsp_w_picpath清空了，也不要吧edits清空了。fsp_w_picpath可以從edits恢復(fù)，而edits清空了，就真沒轍了。

于是，第二天再次停止NN和Standby NN，停止ZKFC，停止JournalNode，結(jié)果NN又起不來了，報

The namenode has no resources availible

一看，恢復(fù)時產(chǎn)生的log太多，元數(shù)據(jù)的硬盤又滿了。只好跟對方合計，把元數(shù)據(jù)換到另外一個比較空的硬盤里處理。我也不知道為什么他們要找那么小的一塊盤存元數(shù)據(jù)，跟操作系統(tǒng)存一起了。挪動元數(shù)據(jù)文件夾，然后改配置，然后啟動ZK,Jounal, NN, StandbyNN，使用bootStrapStandby手工切換主從。再啟動ZKFC，HDFS恢復(fù)，然后強制脫離safemode。touchz和rm測試HDFS可以增刪文件，沒有問題了。

第二次嘗試恢復(fù)，這時實際上HDFS已經(jīng)可以正常訪問，算是恢復(fù)了，但是元數(shù)據(jù)有丟失，這個確實沒辦法了。于是，跟他們商量，采取第二種辦法，嘗試通過日志恢復(fù)元數(shù)據(jù)。他們同意嘗試恢復(fù)。于是將他們自己備份的editslog和fsp_w_picpath從他們自己備份的文件夾拷到元數(shù)據(jù)文件夾，使用recover命令進行editslog到元數(shù)據(jù)的恢復(fù)。經(jīng)過一段時間等待，恢復(fù)，再重啟NN和Standby NN，結(jié)果發(fā)現(xiàn)日志里恢復(fù)出來的數(shù)據(jù)比之前恢復(fù)的還要舊，于是再按第一種方案的下半段方法恢復(fù)成以前的元數(shù)據(jù)。下面說為什么。

最終恢復(fù)出來的元數(shù)據(jù)所記錄的數(shù)據(jù)有580TB多一些，丟失部分數(shù)據(jù)。

1. 原activeNN的日志已經(jīng)被清空, 這上面的fsp_w_picpath是否被動過不知道，之前他們自己操作了什么我不得而知。由于這上面磁盤已滿，所以這上的fsp_w_picpath實際是不可信的。

2. JournalNode沒有做initializeShareEdits，也沒有做ZKformat，所以Journalnode實際上沒有起作用。jn文件夾下無可用做恢復(fù)的日志。方案二中的恢復(fù)是用StandbyNN的日志進行恢復(fù)的，由于standby根本沒有起作用，所以通過日志只能恢復(fù)到做所謂的HA之前的元數(shù)據(jù)。

3. 原standby NN雖然啟動了，也是手工置為standby，但是由于沒有Journalnode起作用，所以雖然DN會上報操作給standby NN，但是無日志記錄，元數(shù)據(jù)也是舊的。最后的日志也就是記錄到5月份，而且已然腦裂。下圖對理解NNHA作用機理非常重要，特別是所有箭頭的指向方向。

   

那么，最后總結(jié)整個問題發(fā)生和分析解決的流程。

先做名詞定義

ANN = Active NameNode

SNN = Standby NameNode

JN = JournalNode

ZKFC = ZooKeeper Failover Controller

問題的發(fā)生：

1. ANN元數(shù)據(jù)放在了一塊很小的硬盤上，而且只保存了一份，該硬盤滿，操作人員在ANN上執(zhí)行了 echo "" > edits....文件的操作。

2. 當初自己做HA，沒有做initializeShareEdits和formatZK，所以JN雖啟動，但實際未起作用，而SNN也實際未起作用。只是假裝當了一個standby？所以JN上無實際可用edits日志。

3. 操作人員在問題發(fā)生后最后備份的實際是SNN的日志和元數(shù)據(jù)，因為ANN editlog已清空，而且ANN硬盤滿，即便有備份，實際也是不可信的。

問題的恢復(fù)：

1. 恢復(fù)備份的fsp_w_picpath，或通過editslog恢復(fù)fsp_w_picpath。

2. 將fsp_w_picpath進行恢復(fù)并重啟NN，JN等相關(guān)進程，在safemode下，Hadoop會自行嘗試進行腦裂的修復(fù)，以當前Acitve的元數(shù)據(jù)為準。

3. 如遇到元數(shù)據(jù)和edits雙丟失，請找上帝解決。這個故障案例麻煩就麻煩在，如果你是rm editslog，在ext4或ext3文件系統(tǒng)下，立刻停止文件系統(tǒng)讀寫，還有找回的可能，但是是echo "" > edits，這就完全沒轍了。而且所有最糟糕的極端的情況全湊在一起了，ANN硬盤滿，日志刪，元數(shù)據(jù)丟，SNN壓根沒起作用，JN沒起作用。

問題的總結(jié)：

1. 作為金主的甲方完全不懂什么是Hadoop，或者說聽過這詞，至于具體的運行細節(jié)完全不了解。

2. 承接項目的乙方比甲方懂得多一點點，但是很有限，對于運行細節(jié)了解一些，但僅限于能跑起來的程度，對于運維和優(yōu)化幾乎無概念。

3. 乙方上層領(lǐng)導認為，Hadoop是可以在使用過程中加強學習和理解的。殊不知，Hadoop如果前期搭建沒有做好系統(tǒng)有序的規(guī)劃，后期帶來的麻煩會極其嚴重。況且，實際上，乙方每個人都在加班加點給甲方開發(fā)數(shù)據(jù)分析的任務(wù)，對于系統(tǒng)如何正常運行和維護基本沒時間去了解和學習。否則，絕對不會有人會執(zhí)行清空edit的操作，而且據(jù)乙方溝通人員描述，以前也這么干過，只是命好，沒這次這么嚴重（所以我懷疑在清空了日志之后肯定還做了其他的致命性操作，但是他們不告訴我）。

4. Hadoop生產(chǎn)集群在初期軟硬件搭建上的規(guī)劃細節(jié)非常之多，橫跨網(wǎng)絡(luò)，服務(wù)器，操作系統(tǒng)多個領(lǐng)域的綜合知識，哪一塊的細節(jié)有缺漏，未來都可能出現(xiàn)大問題。比如raid0或lvm，其實是個大問題，但N多人都不會去關(guān)注這個事。Yahoo benchmark表明，JBOD比RAID性能高出30%~50%，且不會無限放大單一磁盤故障的問題，但我發(fā)現(xiàn)很少有人關(guān)注類似的細節(jié)，很多生產(chǎn)集群都做了RAID0或RAID50。

5. 很多培訓也是魚龍混雜，居然有培訓告訴說map和reduce槽位數(shù)配置沒用，這要不是赤裸裸的騙人，就是故意要坑人。

這是一次非常困難的集群數(shù)據(jù)恢復(fù)的挑戰(zhàn)，最終的實際結(jié)果是恢復(fù)了大約580TB數(shù)據(jù)的元數(shù)據(jù)，并且修復(fù)了腦裂的問題。整個過程沒有使用特殊的命令，全部是hadoop命令行能看到的haadmin, dfsadmin里面的一些命令。整個恢復(fù)過程中需要每個服務(wù)器多開一個CRT，觀察所有進程log的動態(tài)。以便隨時調(diào)整恢復(fù)策略和方法。最后特別提醒一下，seen_txid文件非常重要。

整個過程通過qq遠程方式完成，中間斷網(wǎng)無數(shù)次，在北京操作兩天，在上海操作一天。為保護當事人隱私，以金主和事主代替。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享文章：Hadoop運維記錄系列(十六)-創(chuàng)新互聯(lián)
當前URL：http://aaarwkj.com/article4/jsooe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、動態(tài)網(wǎng)站、品牌網(wǎng)站設(shè)計、搜索引擎優(yōu)化、用戶體驗、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)