Hadoop運維記錄系列(十六)

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

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月份的...這個結果讓人無法直視。

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

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

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

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

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

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

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

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

經過漫長的等待，SNN元數(shù)據(jù)恢復了。但是一直沒有脫離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恢復，而edits清空了，就真沒轍了。

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

The namenode has no resources availible

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

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

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

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

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

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

   

那么，最后總結整個問題發(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硬盤滿，即便有備份，實際也是不可信的。

問題的恢復：

1. 恢復備份的fsp_w_picpath，或通過editslog恢復fsp_w_picpath。

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

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

問題的總結：

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

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

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

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

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

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

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