[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 '1','xufeng-1:2181:/hbase_backup'
list_peers:显示当前master集群一共向哪些集群进行replication
hbase(main):009:0> list_peers PEER_ID CLUSTER_KEY STATE TABLE_CFS 1 xufeng-1:2181:/hbase_backup ENABLED 1 row(s) in 0.0110 seconds
disable_peer:停止向某个slave集群进行replication
hbase(main):010:0> disable_peer '1' 0 row(s) in 0.0110 seconds hbase(main):011:0> list_peers PEER_ID CLUSTER_KEY STATE TABLE_CFS 1 xufeng-1:2181:/hbase_backup DISABLED 1 row(s) in 0.0070 seconds
enable_peer:与disable_peer意义相反
hbase(main):031:0> enable_peer '1' 0 row(s) in 0.0070 seconds hbase(main):032:0> list list list_labels list_namespace list_namespace_tables list_peers list_quotas list_replicated_tables list_snapshots hbase(main):032:0> list_peers PEER_ID CLUSTER_KEY STATE TABLE_CFS 1 xufeng-1:2181:/hbase_backup ENABLED 1 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):065:0> list_replicated_tables TABLE:COLUMNFAMILY ReplicationType replication_source_table:f1 GLOBAL replication_source_table:f2 GLOBAL replication_test_table:f1 GLOBAL 3 row(s) in 0.0190 seconds
show_peer_tableCFs:观察某个slave集群上呗replication的表和列族信息
hbase(main):066:0> show_peer_tableCFs '1' replication_source_table:f1;replication_test_table:f1
5.4 注意点
1. 当replicaion不成功的时候回造成hlog日志积压。即使当前replication都disable状态。
2. replication不会根据实际插入的顺序来进行,只保证和master集群最终一致性。
3. 所有对于replication的shell操作,只对列族为REPLICATION_SCOPE=>'1'才有效。
posted on 2017-03-01 01:19 xf-xrh-xf 阅读(8255) 评论(2) 编辑 收藏 举报