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

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

1. Active的namenode元數(shù)據(jù)硬盤(pán)滿(mǎn)了，滿(mǎn)了，滿(mǎn)了...上來(lái)第一句話(huà)就如雷貫耳。

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

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

因?yàn)橹苣┮ネ獾刂v課，所以無(wú)法去在外地的現(xiàn)場(chǎng)，七夕加七八兩天用qq遠(yuǎn)程協(xié)助的方式上去看了一下。幾個(gè)大問(wèn)題累積下來(lái)，導(dǎo)致了最終悲劇的發(fā)生。

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

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

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

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

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

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

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

經(jīng)過(guò)漫長(zhǎng)的等待，SNN元數(shù)據(jù)恢復(fù)了。但是一直沒(méi)有脫離safemode狀態(tài)，因?yàn)樘砹?，就沒(méi)有繼續(xù)進(jìn)行，只是告訴他們，等到safemode脫離了，就可以了，如果一直沒(méi)有脫離，就強(qiáng)行使用safemode leave脫離。但是，我把一切看的太簡(jiǎn)單了。

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

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

The namenode has no resources availible

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

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

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

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

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

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

   

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

先做名詞定義

ANN = Active NameNode

SNN = Standby NameNode

JN = JournalNode

ZKFC = ZooKeeper Failover Controller

問(wèn)題的發(fā)生：

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

2. 當(dāng)初自己做HA，沒(méi)有做initializeShareEdits和formatZK，所以JN雖啟動(dòng)，但實(shí)際未起作用，而SNN也實(shí)際未起作用。只是假裝當(dāng)了一個(gè)standby？所以JN上無(wú)實(shí)際可用edits日志。

3. 操作人員在問(wèn)題發(fā)生后最后備份的實(shí)際是SNN的日志和元數(shù)據(jù)，因?yàn)锳NN editlog已清空，而且ANN硬盤(pán)滿(mǎn)，即便有備份，實(shí)際也是不可信的。

問(wèn)題的恢復(fù)：

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

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

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

問(wèn)題的總結(jié)：

1. 作為金主的甲方完全不懂什么是Hadoop，或者說(shuō)聽(tīng)過(guò)這詞，至于具體的運(yùn)行細(xì)節(jié)完全不了解。

2. 承接項(xiàng)目的乙方比甲方懂得多一點(diǎn)點(diǎn)，但是很有限，對(duì)于運(yùn)行細(xì)節(jié)了解一些，但僅限于能跑起來(lái)的程度，對(duì)于運(yùn)維和優(yōu)化幾乎無(wú)概念。

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

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

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

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

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

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

文章名稱(chēng)：Hadoop運(yùn)維記錄系列(十六)-創(chuàng)新互聯(lián)
文章來(lái)源：http://weahome.cn/article/jsooe.html