Hbase-12-故障恢复

1.Region Server 宕机的原因：

Full GC导致
网络异常导致
官方Bug 导致
DataNode异常导致

2.故障恢复三部曲

Log Splitting
Distributed Log Splitting
Distributed Log Replay

3.故障恢复流程

这些场景下一旦RegionServer发生宕机，HBase都会马上检测到这种宕机，并且在检测到宕机之后会将宕机RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根据HLog进行丢失数据恢复，恢复完成之后就可以对外提供服务，整个过程都是自动完成的，并不需要人工介入。

其中，Log Splitting 、Distributed Log Splitting 流程如下：

Distributed Log Replay 为

2.1 Master如何检测RS宕机

HBase检测宕机是通过Zookeeper实现的，正常情况下RegionServer会周期性向Zookeeper发送心跳，一旦发生宕机，心跳就会停止，超过一定时间（SessionTimeout）Zookeeper就会认为RegionServer宕机离线，并将该消息通知给Master。

2.2 HLog 切分

HLog 就是将Hlog 按照region进行分组。（参考上一篇文档）

2.2.1、LogSplitting策略：

某台regionserver宕机，/hbase/WALs/bj-hadoop01,123456,789456 为HLog存储在hdfs上的路径。日志切分就是将这个目录下所有HLog文件的所有kv按照region进行分组。

将/hbase/WALs/bj-hadoop01,123456,789456 重命名为 /hbase/WALs/bj-hadoop01,123456,789456-splitting。因为某些场景region server并没有真正宕机，region server与zk网络异常，与外网之间的网络正常，用户并不知道region server宕机，写入更细操作还会继续发送到该region server上。该region server还能继续工作，接收用户请求，不重命名日志文件夹，回放生master已经在使用hlog进行故障恢复了，但region server还在不断的写入hlog，数据不一致。重命名后用户的写请求会异常终止，不会出现数据不一致的情况。客户端丢失数据。
启动读线程一次读取每个HLog中的数据，写入不同的buffer中，每个buffer对应一个region。
切分完成后写成文件。
该方法效率差，切分过程只有master参与，集群宕机，需要恢复大量数据，可能有几百G，master单机切分可能需要几小时。切分过程中一旦出现异常会导致整个集群故障恢复不能正常完成。