本文分析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/