HBase RegionServer故障恢复

 

序

参考：

https://www.jianshu.com/p/569106a3008f  HBase总纲

https://blog.csdn.net/qq_33446500/article/details/105646224  RegionServer宕机回复

 

 

regionServer故障恢复

RegionServer相关的信息保存在ZK中，当regionServer启动的时候，会在ZK上创建临时节点进行注册。

RegionServer通过Socket与ZK建立session会话，周期性的向ZK发送ping包。

 

而HMaster会监控这个下面的所有节点，当发现有临时节点掉落后会启动数据恢复的流程。

RegionServer宕机---》

ZK检测到RegionServer异常---》

Master启动数据恢复----------》

Hlog切分--------------------》

Region重新分配---》

Hlog重放------》

恢复完成并提供服务

 

 

 

故障恢复有三种模式：

Log Splitting 

HMaster全权负责

 

Distributed Log Splitting

Hmaster只进行管理

RegionServer来帮忙

 

Distributed Log Replay

解决DLS的小文件问题

 

 

Log Splitting

在最开始的恢复流程中，Hlog的整个切分过程都由Master来执行：

 

1. 将待切分得到日志文件夹进行重名

防止RegionServer未真的宕机，还在持续写入Hlog

可能就是刚刚说的，或许由于GC导致心跳丢失

HLog是全局RegionServer共享一个

 

1. HMaster启动读取线程读取Hlog的数据，并将不同RegionServer的日志写入到不同的内存buffer中。

HLog保存的数据是一个RegionServer的，里面的数据属于不同的store。

所以固化的时候也要分到不同的文件中。

这里的buffer就等于各个Region数

 

1. 针对每个Buffer，HMaster会启动对应的写线程将不同的Region的Buffer数据写入到HDFS中，

对应的默认路径为：/hbase/table_name/region/recoverd.edits/.tmp

 

 

1. HMaster重新将宕机的RegionServer中的Rgion分配到正常的RegionServer中，对应的RegionServer读取Region的数据，会发现该Region目录下的recoverd.edits目录以及相关的日志，然后RegionServer重放对应的Hlog日志，从而实现Region的数据恢复。

 

从上面的步骤中，我们可以看出HLog的切分一直都是HMaster在干活，效率低下。

如果同时间多个RegionServer宕机，则串行修复。

所以在此基础上提出Distribute Log Splitting  架构

 

 

 

Distributed Log Splitting

其实就是Log Splitting的分布式实现，不仅仅HMaster一个人干活，而是充分使用各个RegionServer上的资源。

利用多个RegionServer来并行切分HLog：

 

 

 

1. HMaster将要切分的日志发布到Zookeeper节点上（/hbase/splitWAL)，每个HLog日志一个任务，初始化为TASK_UNASSIGNED

相当于发布任务

 

1. 在HMaster进行HLog任务发布后，RegionServer采用抢占式认领对应的任务，将状态修改为TASK_OWNED

相当于RegionServer抢占任务

 

 

1. 活跃的RegionServer抢到任务后，会让对应的HLogSplitter线程处理HLog的切分，取出数据，写到不同RegionBuffer中。

 

1. RegionServer启动对应线程，将Region Buffer中的数据写入到HDFS中

路径为:/hbase/table/region/sequenceid.temp

sequenceid 是一个日志中该Region对应的最大sequenceid

如果发现sequenceid不是最大的，则会放弃写入？

如果日志切分成功，则RegionServer会将对应的ZK节点修改为TASK_DONE

失败则会修改为TASK_ERR

1. 如果获得了TASK_ERR，HMaster会进行任务的重新发布。
2. HMaster重新将宕机的RegionServer中的Region分配到正常的RegionServer中，对应的RegionServer读取Region的数据，将该region目录下的一系列的sequenceid.temp进行从大到小重新排放，实现region的数据恢复。

 

以上步骤就是使用多台Region Server来实现Log Splitting 的分布式。

但是会产生许多的小文件：

切分的HLog数 * 宕机RegionServer 上的Region数

比如一个RegionServer有20个Region，有50个Hlog，那么产生的小文件数量为20*50=1000个

 

所以为了避免小文件诞生了 Distributed Log Replay
 

 

 

Distributed Log Replay

 

 

Distributed Log Replay先将宕机RegionServer上的Region分配给正常的RegionServer

并将该Region标记为recovering

recovering 可以对外进行写的服务，但不提供读服务

不能进行split、merge等操作

在使用类似方式进行HLog切分，将HLog的数据转换为RegionBuffer后不写入HDFS，而是进行重放。

 

 

 

HMaster检测宕机

HBase使用Zookeeper协助检测RegionServer宕机，

所有的RegionServer都会在/hbase/rs上创建一个临时节点，被Hmaster watch。

 

这样的好处是很方便，很简单，但是RegionServer在执行GC的时候， Stop-The-World 的时间会停止向ZK发送心跳。

心跳的间隔过长就会导致临时节点离线。

zookeeper.session.timeout进行相关的配置

90s

记得客户端和服务端都要弄

 

 

使用DLR

Distributed Log Splitting 远远优于Distributed Log Splitting方案。

但是由于rolling upgrades场景还是会导致数据丢失，在1.1版本取消了默认设置。

可以使用

hbase.master.distributed.log.replay=true

来开启DLR功能

记得将HFllie格式设置为V3格式（添加了tag功能）