序
参考:
https://www.jianshu.com/p/569106a3008f HBase总纲
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来执行:
- 将待切分得到日志文件夹进行重名
防止RegionServer未真的宕机,还在持续写入Hlog
可能就是刚刚说的,或许由于GC导致心跳丢失
HLog是全局RegionServer共享一个
- HMaster启动读取线程读取Hlog的数据,并将不同RegionServer的日志写入到不同的内存buffer中。
HLog保存的数据是一个RegionServer的,里面的数据属于不同的store。
所以固化的时候也要分到不同的文件中。
这里的buffer就等于各个Region数
- 针对每个Buffer,HMaster会启动对应的写线程将不同的Region的Buffer数据写入到HDFS中,
对应的默认路径为:/hbase/table_name/region/recoverd.edits/.tmp
- 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:
- HMaster将要切分的日志发布到Zookeeper节点上(/hbase/splitWAL),每个HLog日志一个任务,初始化为TASK_UNASSIGNED
相当于发布任务
- 在HMaster进行HLog任务发布后,RegionServer采用抢占式认领对应的任务,将状态修改为TASK_OWNED
相当于RegionServer抢占任务
- 活跃的RegionServer抢到任务后,会让对应的HLogSplitter线程处理HLog的切分,取出数据,写到不同RegionBuffer中。
- RegionServer启动对应线程,将Region Buffer中的数据写入到HDFS中
路径为:/hbase/table/region/sequenceid.temp
sequenceid 是一个日志中该Region对应的最大sequenceid
如果发现sequenceid不是最大的,则会放弃写入?
如果日志切分成功,则RegionServer会将对应的ZK节点修改为TASK_DONE
失败则会修改为TASK_ERR
- 如果获得了TASK_ERR,HMaster会进行任务的重新发布。
- 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功能)