HBase源码分析3—HMaster启动过程

25. 十二月 2017 hbase, 数据库 2

Main Entry

首先找一下启动的入口。从HBase的启动脚本中可以找到类似

从这里确定了入口的包 org.apache.hadoop.hbase.master ,在 HMaster 类中有 main 方法

HMasterCommandLine 继承自 ServerCommandLine ,doMain()执行的是基类的方法,借助 ToolRunner 执行了 HMasterCommandLine.run() 。

看下 HMasterCommandLine 做了什么。run方法做了一些参数检查的工作,最后调用了 startMaster()

startMaster() 里分为两种模式,一种为’local’模式(即默认的standalone模式),在这种模式下会在本机JVM中同时启动master、Region server和Zookeeper,并在最后通过 LocalHBaseCluster 类对所有master、region server等创建现成和提供访问接口。

另一种模式就是distributed模式,就只会构造一个HMaster对象并调用 master.start()

(注: HMaster.constructMaster 返回的实际上是HMaster的构造函数,start的是构造函数)

HMaster

init & wait

HMaster 继承自 HRegionServer,也有Region Server的功能,但是只存储关键的几个表。观察下HMaster.java,前400行基本都是定义了一些管理类,后面有空再慢慢分析这些类分别都是干啥的,先跳过。

HMaster的启动为两个部分,一部分是初始化 HRegionServer和启动 ActiveMasterManager ,这部分在HMaster的构造函数中完成,之后就会进入睡眠状态,等待被zk召唤成为primary master的那天,开始执行第二部分,执行 finishActiveMasterInitialization完成所有成员的初始化以及信息收集、节点管理等,正式接管master工作。

我们先看第一部分, HMaster 的构造函数,初始化了一堆配置然后启动了ActiveMasterManager

ActiveMasterManager 这个对象是用于处理master选举过程的,负责与ZK进行通信,一旦确认成为primary master,会执行 finishActiveMasterInitialization 完成master启动流程。

跟一下 startActiveMasterManager 这个方法,内部先在ZK注册了一下自己为backup master身份,然后启动了一个线程,会hang在这里,等待召唤

blockUntilBecomingActiveMaster 里面是一个while循环,不断尝试注册成为主节点,一但成功就退出。

 

下面我们看看第二部分,当HMaster在ZK注册为primary master后做了什么事。

首先启动了一个监视器 zombieDetectorInitializationMonitor 对象监控master是否在配置的规定时间内初始化完毕,否则认为master启动失败,将会主动退出。

接下来初始化了若干必须的服务,如 fileSystemManagertableLockManager 等,还有若干tracker,他们具体的内容后面我们慢慢研究。

接下来,新的master已选出,整个集群中的region server需要来注册:

waitForRegionServers返回有三个条件(需同时满足):

  • 自上一个region server注册后一个周期时间内没有新的region server注册
  • 总时间超时
  • 注册数量达到配置的最少节点数

如果没有满足,则会一直等待region server过来注册。(极端情况如果hang死这这个地方,会被 InitializationMonitor 干掉,前提是设置了master启动的timeout)

显然这样不能保证所有的region server都过来注册过了,所以还得检查下是谁没来注册,打个log。

Log Splitting

接下来进行的任务是log splitting,因为HBase使用WAL机制,所以当机器宕机的时候内存中未落盘的数据会丢失,但是在WAL日志中可以找到记录做replay。由于每个region server管理多个region,把某个丢数据的region的日志从WAL日志中分离出来的过程就叫log splitting。

为了让master尽快启动,在master初始化阶段只进行hbase:mata的log splitting,

首先看一下 getFailedServersFromLogFolders , 简单说就是去WALs目录下翻日志,关键代码我选一下帖

之前说了master只会做hbase:meta的log splitting,所以要先检查下meta region是不是在failedServer列表里,如果在,那么就进行 splitMetaLogBeforeAssignment分离meta的log。跟进去看下:

一种是ZK模式,一种是通过文件恢复模式。有点复杂,后面研究恢复和WAL的时候细说吧。

Assignment

然后初始化balancer。assign meta

如果assign过了,我们就默默记下就好了。没assign过,要assign一下。在当前版本中, hbase.assignment.usezk 默认是true,可以通过ZK来assign region,一行代码就搞定了。否则我们需要检查一下是不是分配成功,不行的话调用 assignmentManager.assignMeta(hri) 再来一次。。

之后调用 enableMeta(TableName.META_TABLE_NAME) 启用meta。

meta分配完了还得分配存储数据的region,入口是 this.assignmentManager.joinCluster() ,会扫描meta表重建存储结构。

最后

然后后面启动一堆定时操作,balanceChore啥的。

初始化命名空间 initNamespace();

分配meta replica。

一些清理工作。

关闭master启动的监视器,master启动成功。


2 thoughts on “HBase源码分析3—HMaster启动过程”

  • 1
    Anonymous on 2017年12月28日 回复

    博客大好

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据