hbase源碼系列（六）HMaster啟動過程

按照hmaster的run方法的注釋，我們可以了解到它的啟動過程會去做以下的動作。

hmaster是沒有單點問題是，因為它可以同時啟動多個hmaster，然後通過zk的選舉算法選出一個hmaster來。

我們首先來看看這個阻塞直到變成activemaster的過程吧。

1、如果不是master的話，就一直睡，isactivemaster的判斷條件是，在zk當中沒有master節點，如果沒有就一直等待。master節點建立之後，就開始向master沖刺了，先到先得。

2、嘗試着在master節點下面把自己的servername給加上去，如果加上去了，它就成為master了，成為master之後，就把自己從備份節點當中删除。

3、如果沒有成為master，把自己添加到備份節點，同時檢查一下目前的master節點，如果是和自己一樣，那就是出現異常了，明明是設定成功了，确說不成功，接下來它就會一直等待，等到master死掉。

成為master之後的結束初始化操作，這才是重頭戲啊，前面的都是小意思，執行個體化的代碼我就補貼了，看着也沒啥意思，就把這些屬性貼出來吧，讓大家認識認識。

這些類都會被執行個體化，具體的順序就不講了，這個不是特别重要。開學啦，等到region server過來報道，還要記錄一下在zk當中注冊了的，但是沒有在master這裡報道的，不做處理。

okay，下面是重頭戲了，準備配置設定meta表了，先啟動個計時器。

上代碼，從日志檔案裡面找出來挂了的server，然後對這些server做處理。

f3進入getfailedserversfromlogfolders方法。

從代碼上面看得出來，從wals日志的目錄下面找，目錄名稱裡面就包括servername，取出來和線上的server對比一下，把不線上的加到集合裡面，最後傳回。看來這個目錄下都是出了問題的server才會在這裡混。

我們接着回到上面的邏輯，查出來失敗的server之後，從zk當中把之前的meta表所在的位置取出來，如果meta表在這些挂了的server裡面，就糟糕了。。得啟動恢複措施了。。。先把meta表的日志從日志堆裡找出來。我們進入splitmetalogbeforeassignment這個方法裡面看看吧。

可以看出來這裡面有兩種模式，分布式檔案恢複模式，通過zk來恢複，還有一種是recovered.edit模式，通過建立recovered.edits檔案來恢複。檔案恢複是通過hbase.master.distributed.log.replay參數來設定，預設是false，走的recovered.edit模式。看得出來，這個函數是為恢複做準備工作的，如果是分布式模式，就執行preparelogreplay準備日志恢複，否則就開始建立recovered.edits恢複檔案。

a）preparelogreplay方法當中，把hregioninfo.first_meta_regioninfo這個region添加到了recovering-regions下面，置為恢複中的狀态。

b）下面看看splitmetalog吧，它是通過調用這個方法來執行split日志的，通過filter來過濾meta或者非meta表的日志，meta表的日志以.meta結尾。

上面也帶了不少注釋了，不廢話了，進splitlogdistributed裡面瞅瞅吧。

它的所有的檔案的split檔案都插入到一個split隊列裡面去，然後等待結束，這裡面有點兒繞了，它是到zk的splitwals節點下面為這個檔案建立一個節點，不是原來的相對路徑名，是urlencoder.encode(s, "utf-8")加密過的。

呵呵，看到這裡是不是要暈了呢，它是在zk裡面建立一個節點，然後不幹活，當然不是啦，在每個region server裡面讀會啟動一個splitlogworker去負責處理這下面的日志。split處理過程在hlogsplitter.splitlogfile方法裡面，具體不講了，它會把恢複檔案在region下面生成一個recovered.edits目錄裡面。

下面就開始指派meta表的region啦。

曆經千辛萬苦跟蹤到了這個方法裡面，通過rpc，向随機抽出來的region server發送請求，讓它打開region。

這個工作完成, 如果是分布式檔案恢複模式，還需要進行這個工作，recovered.edit模式之前已經幹過了。

之後就是一些清理工作了，處理掉失敗的server，修改一些不正确的region的狀态，配置設定所有使用者的region。

配置設定region的工作都是由assignmentmanager來完成的，在joincluster方法中的調用的processdeadserversandregionsintransition的最後一句調用的assignalluserregions方法，隐藏得很深。。經過配置設定過的region，hmaster在啟動的時候預設會沿用上一次的結果，就不再變動了，這個是由一個參數來維護的hbase.master.startup.retainassign，預設是true。配置設定使用者region的方法和配置設定meta表的過程基本是一緻的。

至此hmaster的啟動過程做的工作基本結束了。