HBase的replication原理及部署

比眉伴天荒 2022-09-11 06:14 83阅读 0赞

一、hbase replication原理  
hbase 的复制方式是 master-push 方式，即主集群推的方式，主要是因为每个rs都有自己的WAL。 一个master集群可以复制给多个从集群，复制是异步的，运行集群分布在不同的地方，这也意味着从集群和主集群的数据不是完全一致的，它的目标就是最终一致性。

Replication 总体结构  
我们直接引用社区的架构图如下，主集群的hlog中记录了所有针对table的变更（目前的ddl不同步），通过实时读取hlog中的entry来解析变更的数据然后发送到从集群中去。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70 2][]

【解释说明】

hbase复制的状态都存储在zookeeper中，默认情况下存储到 /hbase/replication，这个目录有三个子节点： peers znode、rs znode和state。peer 节点管理slave集群在zk上的配置；state节点记录replication运行的状态；rs 节点记录着本集群rs中对应的hlog同步的信息，包括check point信息。（如果人为的删除 /hbase/replication 节点，会造成复制丢失数据）

peers znode：

存储在 zookeeper中/hbase/replication/peers 目录下，这里存储了所有的replication peers，还有他们的状态。peer的值是它的cluster的key，key包括了cluster的信息有： zookeeper，zookeeper port以及hbase在hdfs的目录。

/hbase/replication/peers  
/1 \[Value: zk1.host.com,zk2.host.com,zk3.host.com:2181:/hbase\]  
/2 \[Value: zk5.host.com,zk6.host.com,zk7.host.com:2181:/hbase\]

每个peer都有一个子节点，标示replication是否激活，这个节点没有任何子节点，只有一个boolean值。

/hbase/replication/peers  
/1/peer-state \[Value: ENABLED\]  
/2/peer-state \[Value: DISABLED\]  
rs znode：

rs node包含了哪些WAL是需要复制的，包括：rs hostname，client port以及start code。

/hbase/replication/rs  
/hostname.example.org,6020,1234  
/hostname2.example.org,6020,2856  
每一个rs znode包括一个WAL replication 队列，

/hbase/replication/rs  
/hostname.example.org,6020,1234  
/1  
/2  
\[说明\] hostname.example.org的start code为1234的wal需要复制到peer 1和peer 2。  
每一个队列都有一个znode标示每一个WAL上次复制的位置，每次复制的时候都会更新这个值。  
/hbase/replication/rs  
/hostname.example.org,6020,1234  
/1  
23522342.23422 \[VALUE: 254\]  
12340993.22342 \[VALUE: 0\]

二、replication的配置部署

准备  
既然是集群间的备份那么我们至少需要准备两个HBase集群来进行试验，并且需要满足：  
集群间版本需要一致  
集群间服务器需要互通  
相关表及表结构在两个集群上存在且相同  
2.启用replication步骤  
1> HBase默认此特性是关闭的，需要在集群上（所有集群）进行设定并重启集群，通过手动修改或ambari界面管理在hbase-site.xml配置文件中将hbase.replication参数设定为true。

【参考】

master集群配置文件

hbase.replication true 打开replication功能 replication.source.nb.capacity 5000 主集群每次像备集群发送的entry最大的个数，推荐5000.可根据集群规模做出适当调整,slave集群服务器如果较多，可适当增大 replication.source.size.capacity 4194304 主集群每次像备集群发送的entry的包的最大值大小，不推荐过大 replication.source.ratio 1 主集群里使用slave服务器的百分比 hbase.regionserver.wal.enablecompression false 主集群关闭hlog的压缩 replication.sleep.before.failover 5000 主集群在regionserver当机后几毫秒开始执行failover slave 集群配置文件 hbase.replication true 打开replication功能 2>在主/源集群上和从/目标集群上都新建表：  
create ‘usertable’, ‘family’  
3>在主集群上设定需要向哪个集群上replication数据

add\_peer:增加一个slave集群,一旦add，那么master集群就会向这个slave集群上replication那些在master集群上表列族制定了REPLICATION\_SCOPE=>'1’的信息。  
\[Addpeer\] hbase> add\_peer ‘1’,“zk1,zk2,zk3:2182:/hbase-prod” (zk的地址，端口和Slave的zk address)  
示例：add\_peer ‘1’,‘xufeng-1:2181:/hbase\_backup’ //重要  
set\_peer\_tableCFs ‘1’,‘usertable’  
4>在主集群上打开表student的复制特性

disable ‘usertable’  
alter ‘usertable’,\{NAME => ‘family’,REPLICATION\_SCOPE => ‘1’\} //重要  
enable ‘usertable’  
5>测试replication功能

//上面配置好replication功能后，执行此三条命令会发现slave集群相应的跟着发生了相同变化  
put ‘usertable’,‘row1’,‘family:info’,‘zzzz’  
scan ‘usertable’,\{STARTROW=>‘row1’,ENDROW=>‘row1’\}  
delete ‘usertable’,‘row1’,‘family:info’

set\_peer\_tableCFs：重新设定想slave集群replication哪些表的哪些列族，只对列族REPLICATION\_SCOPE=>'1’有效  
show\_peer\_tableCFs：观察某个slave集群上呗replication的表和列族信息  
append\_peer\_tableCFs：与set\_peer\_tableCFs相比是增量设定，不会覆盖原有信息。  
remove\_peer\_tableCFs：与append\_peer\_tableCFs操作相反。

list\_replicated\_tables：列出在master集群上所有设定为REPLICATION\_SCOPE=>'1’的信息  
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\_peers  
PEER\_ID CLUSTER\_KEY STATE TABLE\_CFS  
1 xufeng-1:2181:/hbase\_backup ENABLED  
1 row(s) in 0.0080 seconds

三、运维经验及遇到的问题  
replication不会根据实际插入的顺序来进行，只保证和master集群最终一致性。  
所有对于replication的shell操作，只对列族为REPLICATION\_SCOPE=>'1’才有效。  
如果写入量较大，Slave 集群必须做好table 的region提前分配，防止写入全部落入1台服务器。  
暂停服务和重新服务期间的数据还是可以被同步到slave中的，而停止服务和启动服务之间的数据不会被同步。也即同步是针对配置replication后复制的新数据，旧数据需要手动迁移  
主集群对于同步的数据大小和个数采用默认值较大，容易导致备集群内存被压垮。建议配置减少每次同步数据的大小  
replication.source.size.capacity4194304

replication.source.nb.capacity2000  
1  
replication目前无法保证region级别的同步顺序性。需要在slave 集群需要打开KEEP\_DELETED\_CELLS=true，后续可以考虑在配置检测到属于slave集群就直接把这个值打开  
stop\_replication后再start\_replication，如果当前写的hlog没有滚动，停止期间的日志会被重新同步过去，类似的如果stop replication后进行了rollhlog操作（手动或重启集群），重新startreplication，新写入的数据不能被马上动态同步过去，需要再rollhlog一次。  
replication.source.ratio 默认值为0.1，这样导致slave集群里只有10%对外提供转发服务，导致这一台压力过大，建议测试环境将此值改为1。  
目前replication 对于压缩的hlog的wal entry 无法解析，导致无法同步配置压缩hlog 集群的数据。这是有数据字典引起的，目前建议主集群中的配置hbase.regionserver.wal.enablecompression设false。  
不要长时间使得集群处于disable状态，这样hlog会不停的roll后在ZK上增加节点，最终使得zk节点过多不堪重负。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70]: /images/20220828/6d7f098e9afe47ca858d974ae6ed608f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70 1]: /images/20220828/5bfec8726c90420a9d16b5bb756ebde2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE4MjE5NzU1_size_16_color_FFFFFF_t_70 2]: /images/20220828/88a34736cb0244cfbf686daea759732b.png