Hbase Replicaition 在腾讯云中应用概述

基本原理

Hbase的Repliation是通过Zookeeper的协助，从Master集群异步往Slave集群写WAL实现的。可以实现典型的Master-Master模式和Master-Slave模式。经过简单的配置即可实现类似下图中的集群复制：

其原理直接引用社区中的架构图就可以看明白，主集群的hlog中记录了所有针对table的变更（目前不支持ddl的复制），通过实时读取hlog中代表事务的WALEdit来解析变更的数据然后发送到从集群中去。

Qcloud Hbase Replication 实现

Qcloud Replication使用的是社区版1.2.4的主从Replication功能。

1.因为当前Replication不支持DDL，所以两个集群都需要提前建立相同的表结构：包括相同的表名和列族。

2.确认都可达，使用vpc的对等网络

https://www.qcloud.com/document/product/215/5000

这里需要注意的是，主从集群的vpc网络不能使用同一网段。

使用对等网络跨地域时，测试ping 大概是30ms左右。

当前私有网络创建和跨地域的对等网络有API支持。

3.如果非跨地域的集群（共用zk集群），需要配置不同的zookeeper.znode.parent。

4.在主从集群上，确认开启配置hbase.replication是true

5.在主集群上，用hbase shell命令：add_peer把从集群作为一个peer

add_peer <ID> <CLUSTER_KEY>

ID ： 是一个唯一的字符串，不能包括连字符

CLUSTER_KEY: 包括从集群的访问地址（zk:port）和对应的zookeeper.znode.parent

比如：

add_peer '1', "10.0.1.179,10.0.1.81,10.0.1.113:2181:/hbase"

查看命令

list_peers

也可以使用命令：enable_peer <ID> disable_peer <ID> remove_peer <ID>来管理从集群。

6.在主集群上，使用命令enable_table_replication来表示哪些表需要复制。

这条命令可能会出现两个集群表不一致情况，先用命令describe <table> 查看是否一致

主要可能是replication_scope不一致，更改方法为：

disable  'test_replication'

alter 'test_replication', {NAME =>'info', REPLICATION_SCOPE => 1}

enable  'test_replication'

7.如果复制开始后，打开了info可以看到日志：

LOG.info("Replicating "+clusterId + " -> " + peerClusterId);

8.验证是否成功

8.1可以直接查看几条记录是否复制过去

create 'usertable','family'

enable_table_replication "usertable"

put 'usertable','rowkey001','family:col1','value01'

get 'usertable','rowkey001', 'family:col1'

8.2 要检查复制的数据是否完整，可以利用hbase提供的小工具verifyrep:

hbase org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication --starttime=1265875194289 --stoptime=1265878794289 1 'usertable'

参数调优参考

1. replication.source.ratio 默认值为0.1， 这样导致slave集群里只有10%对外提供转发服务。如果客户的从集群完全用于容灾没有读请求，可以考虑更改成1。

2.hbase.replication.source.maxthreads，默认值是10，增大可以提高主从replication的吞吐量。

3.replication.source.size.capacity 默认是64M。在replication时一次复制entry包多大数据。和参数replication.source.nb.capacity一起使用，表示最多发多少个entry包，默认是25000。一次太多可能会有问题。可参考Hbase使用的是2M，2000个。

Replication监控

1.可以使用hbase shell命令 status ‘replication’ 来监控复制状态

这个命令会显示出live的RegionServer，并显示这些RegionServer当前的传输状态。

在源端的（SOURCE）：PeerID : 复制连接id; AgeOfLastShippedOp :上一次复制数据给Slave的age(这个指标更详细说明请参考repliation源码分析); SizeOfLogQueue : 当前复制队列的HLog数量; TimeStampsOfLastShippedOp : 上一次复制数据给Slave的时间戳; Replication Lag : 复制延迟时间

在目的端（SINK）:AgeOfLastAppliedOp:上次复制的age; TimeStampsOfLastAppliedOp：上次获得的时间戳

#!/bin/sh  

exec /usr/local/service/hbase/bin/hbase shell <<EOF  

status 'replication'

EOF

2.可以采集在全局RegionServer以及peer(即是从集群)级别的监控数据：拉取jmx的监控即可以看见，直接看也可以到对应的web上metrix dump拉出当时的数据，也可以去采集这些dump数据出来监控。

或者使用curl直接查看对应regionserver的监控记录

curl "http://10.0.0.68:6003/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Replication"

比较方便的方式是直接上任意一台机器使用hbase shell的status ‘replication’查看集群状态，如果发现queue比较长或者时延比较高，再使用jmx接口查看具体的regionser集群状态

最后上rs机器查看日志。一般可以查出问题所在，实在不行只能通过源码分析问题了。（也就是传说中的监控->日志->源码）

故障处理

在Replication中故障包括SourceCluster的RS挂了新增以及SlaveCluster的RS挂了新增。其中SalveCluster的RS新增和挂了比较简单：因为Hbase的Replication是通过异步写WAL的方式，当有RS新增时由hmater分配新的region写即可；当有RS挂了的时候在Source的RS尝试多次RPC写失败后就会认为这个rs挂了，剔除掉后通过Slave zk使用其他的RS。SourceCluster的RS如果有新增，ReplicationManager会在增加一个source并为之分配对应的wal队列。最为复杂的是如果SourceCluster有RS挂了：当有rs挂了，其他Source的RS会去lock住对应的znode，并把其中未完成的hlog的传输挂到自己的zonde名下，再把原来的rs的znode删除。

PS.

1.更详细的原理解析可查看另一篇replication源码解析的文档。

2.最近Hbase1.2.5发布了，有三个和Replication相关的安全更新需要去研究下是否有影响

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338339&projectId=1231075

参考

http://hbase.apache.org/1.2/book.html#_cluster_replication

http://blog.cloudera.com/blog/2012/07/hbase-replication-overview-2/

http://blog.cloudera.com/blog/2012/08/hbase-replication-operational-overview/