HBase宕机恢复

1.HBase常见故障

导致RegionServer故障的原因：

    1、FullGc引起长时间停顿
    2、HBase对Jvm堆内存管理不善，未合理使用堆外内存
    3、Jvm启动参数配置不合理
    4、业务写入或吞吐量太大
    5、写入读取字段太大
    

    HDFS异常：
        读取写入数据都是直接操作hdfs的，若hdfs发生异常，会导致region server直接宕机
        
    机器宕机：
        1、物理节点直接宕机
        2、虚拟云主机不稳定，包括网络环境等
        
    HBase Bug

2.HBase故障恢复

Master恢复：

    1、Master主要负责实现集群的负载均衡和读写调度，没有直接参与用户的请求，所以整体负载并不高
    2、热备方式实现Master高可用，zookeeper上进行注册
    3、active master会接管整个系统的元数据管理任务，zk以及meta表中的元数据，相应用户的管理指令，创建、删除、修改，merge region等

regionServer恢复：

    1、RegionServer宕机，HBase会检测到
    2、Master将宕机RegionServer上所有region重新分配到集群中其它正常的RegionServer上
    3、根据HLog进行丢失数据恢复，恢复之后对外提供服务

大概流程：

    1、master通过zk实现对RegionServer的宕机检测。RegionServer会周期性的向zk发送心跳，超过一定时间，zk会认为RegionServer离线，发送消息给master
    

    2、切分为持久化的日志，所有region的数据都混合存储在同一个hlog文件里，为了使这些数据能够按照region进行组织回放，需要将hlog日志进行切分再合并，
    同一个region的数据合并在一起，方便后续按照region进行数据恢复。
    
    3、master重新分配宕机regionserver上的所有region,regionserver宕机后，所有region处于不可用状态，所有路由到这些region上的请求都会返回异常。
    异常情况比较短暂，master会将这些region分配到其它regionserver上。
    
    4、回放HLog日志补救数据
    
    5、恢复完成，对外提供读写服务

具体流程：

    1、master检测regionserver宕机
        regionserver启动后会在zk的 /rs节点上注册一个临时子节点，超时后临时节点会自动消失，并通知watch在该临时节点上的其它客户端。
        master会watch在/rs节点上，子节点一旦离线会通知master。
        长时间的FullGc也会使得心跳停止。zookeeper.session.timeout,默认180s。对延迟要求高，参数设短。迅速检测到异常，离线集群设置长。
        

    2、切分未持久化数据的HLog
        对HLog中的region进行分组，每个region的数据合并放在一起，方便后续按照region进行回放，这个分组过程称为HLog切分。
        
        2.1、LogSplitting策略：
            某台regionserver宕机，/hbase/WALs/bj-hadoop01,123456,789456 为HLog存储在hdfs上的路径。
            日志切分就是将这个目录下所有HLog文件的所有kv按照region进行分组。
            
            2.1.1、将/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，数据不一致。
                重命名后用户的写请求会异常终止，不会出现数据不一致的情况。
                
                客户端丢失数据
                
            2.1.2、启动读线程一次读取每个HLog中的数据，写入不同的buffer中，每个buffer对应一个region
            
            2.1.3、切分完成后写成文件。
            
            该方法效率差，切分过程只有master参与，集群宕机，需要恢复大量数据，可能有几百G，master单机切分可能需要几小时。
            切分过程中一旦出现异常会导致整个集群故障恢复不能正常完成。
            
        2.2、Distributed Log Splitting:
            master和所有region server的计算能力进行日志切分，master是协调者，region server是实际工作者。
            
            2.2.1、不同region server抢不同的hlog，抢到后发给hlogsplitter线程进行处理，对日志执行具体切分。将数据进行region归类。
            2.2.2、将buffer中的数据写入文件，对数据进行回放。
            
            Distributed Log Splitting 加快故障恢复进程，可以将故障恢复时间降到分钟级别。但会产生很多小文件。
            小文件数：    M * N，
                M：待切分的总Hlog数量
                N：一个宕机region server上的region个数
            一台region server上200个region，90个hlog。宕机后恢复过程会创建18000个小文件。若多个region server宕机，小文件会更多。
            
        2.3、Distributed Log Replay:
            在2.2的基础上不进行文件的写入，而是读取出数据后直接进行回放，大大减少小文件的读写IO消耗。

3.故障消耗时间优化

HBase故障恢复流程：

• 故障检测
• 数据切分
• region上线
• 数据回放

4.优化点

region server在为5000个region切分hlog时，需要为每个region打开一个writer。不同region的数据写到不

同writer，HBase的每一个writer需要消耗3个不同的DataNode各一个Xceiver线程。Xceiver线程主要接收

hdfs客户端发过来的数据包。hdfs上的Xceiver线程个数是有的，默认4096。2台region server宕机，需要消

耗5000 3 2 = 30000个Xceiver线程，超过了hdfs集群的限制，datanode会报错给hbase，耗尽整个hdfsd

集群的Xceiver线程而一直无法恢复。

优化思路：

    控制writer的个数，即使一个region server上的region有5000个，也不能打开5000个writer。

​ 为每个Region设置一个缓冲池，每个region的缓冲池有一个阈值上限，如果遇到一条新的HLog Entry，

发现对应的region缓冲池没有达到上限，则直接写缓冲池，否则选出当前所有缓冲池中超过阈值的缓冲池集

合，将这个集群中的缓冲池一次刷新成hdfs上一个新文件。这个过程是放到writer池中完成的，能保证在任意

时刻最多只有指定个数的writer在写数据文件。不会造成Xceiver耗尽。