关于hbase: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 耗尽。