[How to]HBase集群备份方法--Replication机制

1.简介

　　HBase备份的方法在[How to]HBase集群备份方法文章中已经有些介绍，但是这些方法都不是HBase本身的特性在支持，都是通过MR计算框架结合HBase客户端的方式，或者直接拷贝HBase的底层hdfs数据的方式进行备份的，但从操作上来说也比较繁琐复杂，数据完整性和及时性上也做的并不是很好。

　　本文介绍另外一种集群间的数据自动备份特性，这个特性是HBase的内部特性，用户数据备份和数据容灾和集群功能划分。

　　数据容灾可以认为只是为了数据的保存的措施，除此之外我们也可以灵活使用这种机制通常其能够适用于如下场景：

• 数据备份和容灾恢复

• 数据归集

• 数据地理分布

• 在线数据服务和线下数据分析

2.前准备

　　既然是集群间的备份那么我们至少需要准备两个HBase集群来进行试验，准备如下HBase集群。在测试环境上准备有两套HBase集群，资源有限原因他们共享一个hdfs集群和zookeeper，通过配置不同node路径和hdfs上数据路径来区别开。

　　　　

　　　　

　　其中xufeng-3作为源集群，xufeng-1作为目标集群

1.集群间版本需要一致
2.集群间服务器需要互通
3.相关表及表结构在两个集群上存在且相同 

3.启用Replication步骤

　　1. HBase默认此特性是关闭的，需要在集群上（所有集群）进行设定并重启集群，将hbase.replication参数设定为true

  <property>
    <name>hbase.replication</name>
    <value>true</value>
  </property>

　　2.在源集群上和目标集群上都新建表：

hbase(main):006:0> create 'replication_source_table','f1','f2'
0 row(s) in 0.3920 seconds

=> Hbase::Table - replication_source_table

　　3.在源集群的表上标注出需要备份的列族信息，如下将进行对于f1列族下数据的replication

hbase(main):008:0> alter 'replication_source_table',{NAME=>'f1', REPLICATION_SCOPE=>'1'}
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.2830 seconds

　　4.现在设定需要向那个集群上replication数据，在hbase shell中执行命令。下面的命令指明了目标集群的zookeeper地址，以及它在这个zookeeper上路径，有了这些信息

　　相当于就知道了整个目标集群的信息。

hbase(main):010:0> add_peer '1',"xufeng-1:2181:/hbase_backup"
0 row(s) in 0.1220 seconds

　　5.通过shell命令可以看到目标集群已经被 添加到了源集群的replication中。

hbase(main):013:0> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup ENABLED
1 row(s) in 0.0450 seconds

　　6.现在我们在步骤3上被作为replication的表上进行数据的插入

hbase(main):005:0> scan 'replication_source_table'
ROW                     COLUMN+CELL
 row1                   column=f1:a, timestamp=1469939791335, value=f1-a
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b
 row3                   column=f2:a, timestamp=1469939814071, value=f2-a
 row4                   column=f2:b, timestamp=1469939821430, value=f2-b
4 row(s) in 0.0610 seconds

　　7.查看xufeng-1的目标集群上的同名的表上是否有数据产生？

hbase(main):007:0> scan 'replication_source_table'
ROW                     COLUMN+CELL
 row1                   column=f1:a, timestamp=1469939791335, value=f1-a
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b
2 row(s) in 0.0340 seconds

hbase(main):008:0> 

　　可以看到源集群表上的f1列族下的数据都被replication到了目标集群的对应表中。（f2列族并没有设定replication的scope，所以不会被赋值）

　　8.进一步的我们在源集群表上删除一行row1行这个数据：

hbase(main):009:0> delete 'replication_source_table','row1','f1:a'
0 row(s) in 0.0200 seconds

　　查看对应的目标集群表数据，数据同样被删除

hbase(main):009:0> scan 'replication_source_table'
ROW                     COLUMN+CELL
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b
1 row(s) in 0.0230 seconds

　　9.如果要停止对于某个集群的replication，可以执行disable_peer，同样的要想再次开启可使用enable_peer，更多关于使用方法可在hbase shell中的help中查看：

  Group name: replication
  Commands: add_peer, append_peer_tableCFs, disable_peer, enable_peer, list_peers, list_replicated_tables, remove_peer, remove_peer_tableCFs, set_peer_tableCFs, show_peer_tableCF 

4.replication应用场景

　　数据容灾可以认为只是为了数据的保存的措施，除此之外我们也可以灵活使用这种机制通常其能够适用于如下场景：

• 数据备份和容灾恢复

• 数据归集

• 数据地理分布

• 在线数据服务和线下数据分析

　　多个集群间的互相备份可以形成集群间的拓扑结构：如下不同地域间的集群合一将数据放置到某个中心备份集群上，中心备份集群会将需要做分析的数据同步到数据分析集群，经过数据分析后将结果同步到其他业务集群上。

　　　　　　　　　　　　　　

5.Replication原理

　　5.1 概要：

　　Replication是使用协处理器的Endpoint来实现的，基本原理是将源集群的regionserver会将WAL日志按顺序读取，并将WAL日志读取日志offset等信息通过zookeeper记录，读取之后主动的想目标集群的regionserver发送这些信息，在目标集群的regionserver接收到信息后会使用HTable客户端将这些信息插入的对应的表中。源集群的regionserver是endpoint的客户端，目标集群上的regionserver有endpoint的服务端实现，两者通过protobuf协议实现RPC通信，基于这一点所以需要集群间的版本一致，网络互通。

官方上给出的原理图如下：

　　　　　　　　　　　　　　　　　

　　对于Replication机制来说他是通过Endpint来时实现的，这一点从其源代码上既能看出：

　　　　　　　　　　　　　　　

　　对于其原理上来说官方的说明图并不清晰，这里我自己画了一个尝试去解释：

　　　　　　　　　　　　　　

　　对于源集群上的Regionserver来说其自身就是Endpoint的客户端，她通过读取自己所持有的hlog日志（当其他机器死掉时候也会接管其他regionserver的hlog日志）然后同步调用rpc机制去向远端目标集群上的regionserver发送信息并等待相应，目标集群上并不是所有的regionserver都参与到接受信息的活动中，源集群会通过zookeeper来watch到目标集群上的所有rs信息然后根据比例（可配）的服务器个数来参与到replication中。目标集群上的regionserver的endpoint服务端接受到这些信息就会通过普通的htable客户端API进行数据的put，最后会返回结果给源集群的调用者，调用者会记录下hlog日志的offset信息保存。然后继续读取和发送。所以总体而言replication需要hlog作为数据源，解析hlog发送到远端regionserver，远端regionserver通过api将数据插入到对应表中去。

　　对于以上分为两部分，一部分是源集群是如何运行的，目标集群上是如何相应的来解释。

5.2 Replication机制

　　zookeeper节点介绍：

　　对于目标集群或者说slave集群来说，他是服务端，被动的接受来自客户端也就是源集群或者说master集群的请求，接受到请求后再包装成操作进行API的调用将数据插入到自身集群。

从这一点来看，主要工作都是master集群来完成的，前面也介绍replication机制是通过读取hlog来记性数据重建的。并且通过zookeeper来记录当前replication的进度，所以我们先看一下在zookeeper中是如何定义Replication的：

　　　　　　　　　　　　

从上图可以看到/peers中记录着master集群要向哪些slave集群进行replication，并且知道某个slave集群上需要replication哪些表的那些列族信息。

/rs中节点记录着当前master集群的所有regionserver信息，每一个regionserver中又记录着这个regionserver上需要向哪些slave集群replication信息，并且知道向某个salve集群上那些hlog需要被replication，和当前某个hlog被replication的进度信息。

　　master集群regionserver的宕机处理：

　　master集群的每一个regionserver都会负责其所持有的hlog日志，但是当某台宕机之后会做什么处理呢？

　　

　　1. master集群上的regionserver都会通过zookeeper来相互watch。

　　2.当某台宕机后，其他rs会去其节点下抢注lock节点，如上图，1.1.1.2宕机，1.1.1.3注册到了lock节点，他会将1.1.1.2的信息赋值到其几点下，1.1.1.2的节点信息将会以peer_id-1.1.1.2rs信息为节点被写入1.1.1.3节点下，他会开启一个新线程去处理1.1.1.2的hlog信息。

　　3.但是如果1.1.1.3也宕机了，那么1.1.1.1最为最后的rs将会写入lock节点，然后按照同样的方式去处理。

　　

　　master集群rs上hlog归档机制：

　　hlog会被RS进行归档，也就是说hlog的路径会被修改，当归档后，记录在zookeeper上的hlog节点信息会更新其路径，一般的：

　　1.当这个hlog文件还没有被replication被读取，那么会更新路径。

　　2.当hlog正在被replication读取中，则不会更新路径信息，因为hlog路径的改变只是一个namenode上逻辑信息的改变，既然已经在读取了，去块分布式不会被修改的。

　　3.只要master集群开启的replication机制，并且add了peer，那么即使这个peer是disable，hlog都不会被删除，而是需要等待replication对这些hlog读取完毕后才能被删除。

5.3 shell命令详解：

　　shell环境我们提供了很多方法去操作replication特性：

  Group name: replication
  Commands: add_peer, append_peer_tableCFs, disable_peer, enable_peer, list_peers, list_replicated_tables, remove_peer, remove_peer_tableCFs, set_peer_tableCFs, show_peer_tableCFs

add_peer:增加一个slave集群,一旦add那么master集群就会向这个slave集群上replication那些在master集群上表列族制定了REPLICATION_SCOPE=>'1'的信息。

add_peer '','xufeng-1:2181:/hbase_backup'

list_peers：显示当前master集群一共向哪些集群进行replication

hbase(main)::> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
  xufeng-::/hbase_backup ENABLED
 row(s) in 0.0110 seconds

disable_peer:停止向某个slave集群进行replication

hbase(main)::> disable_peer ''
 row(s) in 0.0110 seconds

hbase(main)::> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
  xufeng-::/hbase_backup DISABLED
 row(s) in 0.0070 seconds

enable_peer:与disable_peer意义相反

hbase(main)::> enable_peer ''
 row(s) in 0.0070 seconds

hbase(main)::> list
list                     list_labels              list_namespace
list_namespace_tables    list_peers               list_quotas
list_replicated_tables   list_snapshots
hbase(main)::> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
  xufeng-::/hbase_backup ENABLED
 row(s) in 0.0080 seconds

set_peer_tableCFs：重写设定想slave集群replication哪些表的哪些列族，只对列族REPLICATION_SCOPE=>'1'有效

append_peer_tableCFs：与set_peer_tableCFs相比是增量设定，不会覆盖原有信息。

remove_peer_tableCFs：与append_peer_tableCFs操作相反。

list_replicated_tables：列出在master集群上所有设定为REPLICATION_SCOPE=>'1'的信息

hbase(main)::> list_replicated_tables
TABLE:COLUMNFAMILY           ReplicationType
 replication_source_table:f1 GLOBAL
 replication_source_table:f2 GLOBAL
 replication_test_table:f1   GLOBAL
 row(s) in 0.0190 seconds

show_peer_tableCFs：观察某个slave集群上呗replication的表和列族信息

hbase(main)::> show_peer_tableCFs ''
replication_source_table:f1;replication_test_table:f1

5.4 注意点
　　1. 当replicaion不成功的时候回造成hlog日志积压。即使当前replication都disable状态。
　　2. replication不会根据实际插入的顺序来进行，只保证和master集群最终一致性。
　　3. 所有对于replication的shell操作，只对列族为REPLICATION_SCOPE=>'1'才有效。