《HBase原理与实践》阅读笔记（四）

本博客内容基本整理自《Hbase原理与实践》一书。仅用于个人学习和积累。

1.宕机恢复原理

HBase系统中主要有两类服务进程：Master进程以及RegionServer进程。因此宕机异常也主要发生在这两个进程上。其中由于Master主要负责集群管理调度，在实际生产线上并没有非常大的压力，因此发生软件层面故障的概率非常低。

1.1.RegionServer宕机异常

• Full GC异常： 长时间的Full GC是导致RegionServer宕机的最主要原因，据不完全统计，80%以上的宕机原因都和JVM Full GC有关。
• HDFS异常： RegionServer写入读取数据都是直接操作HDFS的，如果HDFS发生异常会导致RegionServer直接宕机。
• 机器宕机： 物理节点直接宕机也是导致RegionServer进程挂掉的一个重要原因。通常情况下，物理机直接宕机的情况相对比较少，但虚拟云主机发生宕机的频率比较高。
• Hbase本身Bug。

1.2.Hbase故障恢复

1.2.1.Master故障恢复原理

HBase采用基本的热备方式来实现Master高可用。即在集群中至少启动两个Master进程。一个为Active Master，一个为Backup Master。

1.2.2.RegionServer故障恢复原理及流程

下图为RegionServer故障恢复的流程示意图：

第一步检测很好理解，Hbase使用ZooKeeper协助Master检测RegionServer宕机。

第二步，由于HBase在数据写入内存之前都先写入HLog，因此当RegionServer宕机时，写入内存中的那部分数据就丢失了，此时就需要HLog文件来恢复数据。
当前版本中，一台RegionServer默认只有一个HLog文件，即所有Region的日志都是混合写入该HLog的。然而，日志回放需要以Region为单元进行，一个Region一个Region地回放，因此在回放之前首先需要将HLog按照Region进行分组，每个Region的日志数据合并放在一起，方便后面按照Region进行回放。这个分组合并过程称为HLog切分。
目前版本主要使用DLR（Distributed Log Replay）做为HLog切分方案。用户可以通过设置参数hbase.master.distributed.log.replay=true来开启DLR功能，当然前提是将HFile格式设置为v3（v3格式HFile引入了tag功能，replay标示是用tag实现的）。

完成第二步的切分工作之后，第三步中Master会将宕机RegionServer上的Region重新分配到其他可用的RegionServer上。

第四步的作用就是将第二步中切分好的HLog数据回放到第三步重新分配的Region中去，从而完成丢失数据的恢复工作。

当上面步骤都完成后，Region才会重新上线，对外提供读写服务。

2.复制

为了实现跨HBase集群的数据同步，HBase提供了非常重要的复制功能。HBase默认采用异步复制方式，这种方式可以满足大部分应用场景。此外还有串行复制和同步复制用于解决其他一些需求。

2.1.HBase复制管理流程

HBase 2.x版本复制管理流程：

其中，Peer指一条从主集群到备份集群的复制链路。

2.1.1.HBase客户端创建Peer流程

• 将创建Peer的请求发送到Master。
• Master内实现了一个名为Procedure的框架。对于一个HBase的管理操作，我们会把管理操作拆分成N个步骤，Procedure在执行完第i个步骤后，会把这个步骤的状态信息持久化到HDFS上，然后继续跑第i+1个步骤。这样，在管理流程的任何一个步骤k出现异常，我们都可以直接从步骤k接着重试，而不需要把所有N个步骤重跑。对于创建Peer来说，Procedure会为该Peer创建相关的ZNode，并将复制相关的元数据保存在ZooKeeper中。
• Master的Procedure会向每一个RegionServer发送创建Peer的请求，直到所有的RegionServer都成功创建Peer；否则会重试。
• Master返回给HBase客户端。

2.2.串行复制

Region从一个RegionServer移动到另外一个RegionServer的过程中，Region的数据会分散在两个RegionServer的HLog上，而两个RegionServer完全独立地推送各自的HLog，从而导致同一个Region的数据并行写入Peer集群。这种情况下就需要串行复制。
该功能目前已整合到HBase 2.x分支上。

2.3.同步复制

同步复制的核心思想是，RegionServer在收到写入请求之后，不仅会在主集群上写一份HLog日志，还会同时在备份集群上写一份RemoteWAL日志。只有等主集群上的HLog和备集群上的RemoteWAL都写入成功且MemStore写入成功后，才会返回给客户端，表明本次写入请求成功。除此之外，主集群到备集群之间还会开启异步复制链路，若主集群上的某个HLog通过异步复制完全推送到备份集群，那么这个HLog在备集群上对应的RemoteWAL则被清理，否则不可清理。因此，可以认为，RemoteWAL是指那些已经成功写入主集群但尚未被异步复制成功推送到备份集群的数据。

2.3.1.同步复制中集群的四种状态

• Active（简称A）：这种状态的集群将在远程集群上写RemoteWAL日志，同时拒绝接收来自其他集群的复制数据。一般情况下，同步复制中的主集群会处于Active状态。
• Downgrade Active（简称DA）：这种状态的集群将跳过写RemoteWAL流程，同时拒绝接收来自其他集群的复制数据。一般情况下，同步复制中的主集群因备份集群不可用卡住后，会被降级为DA状态，用来满足业务的实时读写。
• Standby（简称S）：这种状态的集群不容许Peer内的表被客户端读写，它只接收来自其他集群的复制数据。同时确保不会将本集群中Peer内的表数据复制到其他集群上。一般情况下，同步复制中的备份集群会处于Standby状态。
• None（简称N）：表示没有开启同步复制。

集群的复制状态可以从其中一种切换到另一种状态。

2.3.2.同步复制建立过程

1）在主集群和备份集群分别建立一个指向对方集群的同步复制Peer。这时，主集群和备份集群的状态默认为DA。
2）通过transit_peer_sync_replication_state命令将备份集群的状态从DA切换成S。
3）将主集群状态从DA切换成A。

3.总结

第九章宕机恢复原理中介绍了一些常见的故障分析，其中提到的Full GC异常占了RegionServer宕机原因的80%以上。但是JVM这一块的基础很薄弱，对于书中提到的Java堆内内存管理和JVM启动参数设置等看的是一头雾水，所以这里先标记一下，Java虚拟机相关的知识后续需要安排起来。第十章关于跨HBase集群的数据同步，HBase提供了复制功能实现。这个很好理解，将这个集群的数据复制到另一个集群数据当然实现了同步，但是其中的实现却远比想象中的复杂，毕竟这不是简单的复制粘贴操作，涉及到了集群的状态，数据拷贝时的顺序，Region的对应关系等等。这一部分自己之前没怎么接触过，因此不是特别能看懂，后续会找一些相关博客或者文章再学习一下，并对本博客进行更新。