1、Master负载并不很高,基本采用热备的方式来实现Master高可用
2、RegionServer宕机的恢复主要原因有。
2.1、Full GC异常
2.2、HDFS异常
2.3、物理节点宕机
2.4、HBase Bug
3、RegionServer故障恢复原理
3.1、利用ZK临时节点机制,RS在启动会在ZK注册成临时节点,同时Master会Watch这个节点,一般情况下RegionServe会周期性的向ZK发送心跳,如果在超时时间内没有收到心跳,临时节点就会离线,这个消息马上会通知给到Master,Master检测到RS宕机
3.2、切分未持久化的HLog日志,HLog包含多个Region的数据,为了能够按照Region一个个进行数据恢复,首先需要对HLog按照Region进行分组。把同一个Region的日志放一块,便于一个个Region回放。
3.3、Master重新分配宕机RegionServer上的region,将这些Region重新分配到其他可用的RS上。
3.4、按照Region回放HLog
3.5、完成修复,对外提供服务
4、HLog切分大有学问
4.1、0.96版本之前的切分策略:Master单机切分HLog
4.1.1、将待切分的日志重命名,主要防止在某些情况下RS并没有真正宕机,但是Master已经在进行故障恢复了,但是RS还在接受写入请求导致数据不一致。重命名之后此时用户的请求就会异常终止。
4.1.2、读取HLog数据对数据按照Region分组。
4.1.3、切分完成之后Master会对每个Region HLog数据写入各个Region对应的HDFS目录。
4.1.4、Region对日志按顺序进行会回放。
缺点:如果需要恢复的数据有几十G 或者更大,Master单机切片的搞法可能需要数小时。
4.2、分布式切分HLog策略
4.2.1、Master将待切分的日志路径发布到ZK节点上,每个日志为一个任务,每个任务都有对应的状态,起始状态为TASK_UNASSIGNED
4.2.2、RS启动之后都注册这个节点等待新任务,一旦Master发布任务,RS就会抢占该任务
4.2.3、抢占任务先看任务状态,如果是TASK_UNASSIGNED,则说明没有被抢占,然后尝试去修改状态为TASK_OWEND,如果修改成功,表名任务抢占成功。如果修改失败说明被别的RS抢占了。
4.2.4、RS抢占任务成功了之后,将任务分给相应的线程处理,如果处理成功则修改状态为TASK_DONE;如果失败,则状态修改为TASK_ERR。
4.2.5、Master一直监听ZK节点状态的变更,如果状态为TASK_ERR,则重新发布任务,如果成功则删除对应的节点。
4.2.6、分布式切分举例
1)假设Master当前发布了4个任务,即当前需要回放4个日志文件HLog1(H1)、HLog2(H2)、HLog3(H3)、Hlog4(h4)
2)假设RS1抢占了H1,H2;RS2抢占了H3;RS3抢占到了H4
3)以RS1为例,他会把H1,H2,分给2个HlogSpliter线程进行处理,HLogSpliter负责对日志文件执行具体的切分,
具体切分步骤用4.1策略差不多
优点:通过多RS同时执行HLog切分,解决了Master单机切分带来的耗时长的问题
缺点:假设一个宕机的RS上有200个Region,有90个Hlog,由于每个HLog都需要按Region分组,所以这种切分方法会产生90*200=18 000 个小文件。
4.4、分布式日志回放策略
相比分布式切分HLog策略,流程上主要改动了两点
1)、不是先切分在分配Region,而是先分配Region之后再进行Hlog切分,并且此时的Region是recovering状态,可以对外提供写服务
2)、切分HLog逻辑同4.2区别是分布式回放策略并没有先写入文件,而是直接回放。
这种设计大大减少小文件的IO消耗,解决4.2的短板。
网友评论