HBase RegionServer宕机处理恢复
本文分析RegionServer宕机后这个region server上的region是如何在其他region server上恢复的。
region server宕机后发生了什么
HMaster有一个RegionServerTracker对象,监控zk上/hbase/rs目录下的结点,达到监控region server下线的目的。一个region server宕机后,zk上相应结点删除,触发RegionServerTracker的nodeDeleted(),方法调用ServerManager的expireServer逻辑,对于非meta region(0.96后只有一个meta region),提交一个ServerShutdownHanlder的任务给内部线程池处理,任务的处理逻辑在handler的process()中。HBASE-7006引入了distributed log replay特性,这里以distributed log replay为例。如果开启了distributed log replay特性,那么在zk上建立一系列结点/hbase/recovering-regions/regionEncodeName/serverName,其中regionEncodeName结点内容为该region的last flush sequence id,即这个sequence id之前的所有数据都已经flush到磁盘上产生了HFile文件,这部分数据不需要进行回放。serverName结点的内容为宕机的region server上的last flushed sequence id,即所有region中最大的last flush sequence id。将宕掉server上的region assign通过round robin的方式assign其他的活着的region server,然后提交一个LogReplayHandler的任务给内部线程池,这个任务内部就是进行split log的准备工作,将hdfs上该region server的log改名,加上-splitting后缀,变成hbase.rootdir/WALs/serverName-splitting,然后进入HMaster的SplitLogManager管理范围,在zk上建立节点,路径/hbase/splitWAL/对上面改写后的log路径的encode。然后HMaster等待log被其他region server上的SplitLogWorker split完成,然后将一开始建立的一系列节点/hbase/recovering-regions/regionEncodeName/serverName删掉,然后将-splitting目录删除.
regionserver上的SplitLogWorker会不断的去监控zk上的hbase.rootdir/WALs/serverName-splitting节点,并且试图own这个节点.成功后,则给SplitLogWorker内部线程池提交一个HLogSplitterHandler任务,任务逻辑在对象splitTaskExecutor中,任务内部主要调用HLogSplitter.splitLogFile(),从而进到HLogSplitter的boolean splitLogFile(FileStatus logfile, CancelableProgressable reporter) throws IOException. 该函数内部会读-splitting目录内部的hlog文件,然后将每条log entry加入到一个sink中,sink是一个抽象类,根据是否配置使用distributed log replay,使用不同的子类,对于distributed log replay来说,使用LogReplayOutputSink,否则使用LogRecoveredEditsOutputSink。回到函数boolean splitLogFile(FileStatus logfile, CancelableProgressable reporter) throws IOException,函数的逻辑主要是从hlog中解析出一条条的log entry,如果log entry的sequence id比zk上相应的/hbase/recovering-regions/regionEncodeName 节点记录的sequence id小,那么说明这条log entry对应的内容已经持久化在HFile中,不需要进行回放,否则将这条日志append到成员EntryBuffers对象中,EntryBuffers内部会对log entry按照region进行分组,同一个Region的log entry记录在对象RegionEntryBuffer中。同时,会有一些写线程,不断的从EntryBuffers中取出RegionEntryBuffer对象,将其append到sink中,在这里,是LogReplayOutputSink。LogReplayOutputSink中积攒到一批日志,会调用WALEditsReplaySink的replayEntries()方法,通过ReplayServerCallable这个rpc发给这个region被assign后的新的region server让其回放,由于这里使用多个写线程给其他的region server发送日志,所以叫作distributed log replay。
非distributed log replay的模式下,LogRecoveredEditsOutputSink的工作是直接按照region,把相对应的log写到hdfs的 hbase.rootdir/data/namespace(比如test)/table_name/region_encoded_name/recovered.edits下。后续region被其他region server open时,会来这看是不是有需要回放的hlog.
需要注意的是,在distributed log replay模式下,region是被open后,然后才replay ,可以看到open成功后,这个region可以提供写,但是不能提供读,因为数据不全。
以上是region server宕机后,触发的HMaster和其他region server的逻辑。
下面看看region server 收到HMaster的open region指令的逻辑。
Open Region
如果是distributed log replay,那么会去zk上找 /hbase/recovering-regions/regionEncodeName/serverName,将region记录在map recoveringRegions中。然后如果不是meta region,则提交一个OpenRegionHandler任务到内部线程池中,任何的逻辑主要是open region,代码在openHRegion(final CancelableProgressable reporter),最后主要代码在initializeRegionInternals()内部调用initializeRegionStores()方法中。这个方法主要就是从hdfs中load region对应的HFile文件,并且如果region目录下的recovered.edits有hlog文件需要回放,则进行回放(方法replayRecoveredEditsIfAny)。
加载HFile过程中很重要的一点是,需要将这个HRegion下的所有的HStore(一个column family对应一个HStore,一个HStore下面有多个HFile和一个memstore)中最大的memstoreTS拿出来,加1后去初始化HRegion内部的mvcc对象,这个对象用于负责实现MVCC。这个时间戳相当于事物ID,用来判断数据是否对某事务可见。
参考资料
hbase-server-0.98.3-hadoop2.jar
https://issues.apache.org/jira/browse/HBASE-7006
http://blog.cloudera.com/blog/2012/07/hbase-log-splitting/