Hbase Replication 介绍

Hbase Replication 介绍

现状

     Hbase 的replication目前在业界使用并不多见,原因有很多方面,比如说HDFS目前已经有多份备份在某种程度上帮助HBASE底层数据的安全性,而且很多公司的集群规模比较小并且对数据重要程度并不是很高,比如一些日志系统或者是作为一个历史数据的第二个仓库,来分流大量的读请求。这样及时数据丢失了也可以在其他的地方(数据库集群)中找回来。对于这样的情况Replication的Slave集群变得可有可无,重要性根本得不到体现。故如果管理员把hbase只作为一个低安全级别和非重要业务的一个管理平台,那么下面对于Replication集群的讨论可以不用浪费时间来阅读。目前阿里集团有相当重要的应用存在于Hbase之上,包括在线和非在线的应用。那么Hbase数据的安全性也显得弥足重要。对于单集群的存在的问题通常来自以下几个方面:

  • 数据管理人员的失误,不可逆的DDL操作。
  • 底层HDFS文件BLOCK块corruption
  • 短时间过度的读数据对集群造成的压力,增加服务器应对这种情况比较浪费资源。
  • 系统升级,维护,诊断问题会造成集群不可用时间增长。
  • 双写的原子性难以保证
  • 不可预计的一些原因。(如机房断电,大规模硬件损坏,断网等)
  • 离线应用的MR计算对在线读写造成的较大的延迟影响
如果为以上问题担忧的话,Replication构建主被集群则是一种很好的选择,我们也在这方面的做了一些简单的研究。下面简单说下我们的使用中遇到的问题和采取的方法

常用的在线备份方案及其比较

对于数据中心的数据冗余的备份方案,目前从一致性,事务性,延迟,吞吐量,数据损失,Failover几个角度来分析有一下几种方案。

•       简单备份模式通过定时不定时的Dump出集群数据保证数据的安全性,通常可以通过snapshot或设置时间戳来dump数据来实现这种方案,如果方案简介,设计优雅可以做到对在线数据中心低干扰或无干扰的数据备份。但这种方案缺点也是显而易见的,只是对时间点之前的数据安全性得到保障,如果发生突发事件会导致不可避免的整段时间的数据丢失,为很多人无法接受。

•       主从模式(Master-Slave)这种模式比起简单的备份模式多了很多优点,可以通过最终一致性保证数据的一致,数据从主集群到备集群延时较低,异步写入不会对主集群带来性能压力,基本不会产生多少性能的影响,突发事件来临时数据丢失很少,并且主集群的事务在备集群也可以得以保证。一般通过构造较好的Log系统加上check Point来实现,可以实现读写分离,主集群可以担当读写服务,但备集群一般只承担读服务。

•       主主模式 (Master-Master)原理总体类似于主从模式,不同的是2个集群可以互相承担写的分离,都可承担读写服务。

•       2阶段提交这种方案保证了强一致性和事务,服务器返回给客户端成功则表明数据一定已经成功备份,不会造成任何数据丢失。每台服务器都可承担读写服务。但缺点是造成集群延迟较高,总体吞吐下降。

•       Paxos算法基于Paxos算法的实现的强一致性方案,同一客户端连接的server能保证数据的一致性。缺点是实现复杂,集群延迟和吞吐随着集群服务器增加而边差。

我们可以通过下面的一个图标来说明简化一下上面各种模式的特点。

 

备份

主从

主主

2PC

Paxos

数据一致性

保证最终一致性

 

强一致性

 

事务

主集群保证

分别保证

主集群保证

主集群保证

延迟

吞吐量

数据丢失

大量

最近短暂时间丢失

最近短暂时间丢失

无丢失

无丢失

集群服务

无服务

主读写从只读

读写

读写

读写



•       Hbase Replication主从模式通过指定备集群,将Hlog里面的数据异步发送到备集群,对主集群基本没有性能影响,数据延时时间较短。主集群提供读写服务,备集群提供读服务。如果主集群有故障,可以快速切换到备集群。回过头来我们可以看看Hbase的备份状况,Hbase可以同过离线备份和在线备份提供上述的简单备份模式,主从和主主三种备份模式模式

•       Hbase 简单备份模式如果表不在线比较好办,可以通过copy table或者是distcp + add table来解决。如果表在线并且不能让其下线,只有通过snapshot方案对onlinetable实施备份(关于snapshot原理我发另一篇文章来解释)。

•       Hbase Replication主主模式2个集群互为主备,都提供读写服务,读写分离。

通过比较,总体看来hbaseReplication的解决方案可以很好的解决集群安全性,数据安全性,读写分离,运维和客户操作失误等等的问题,并且易于管理和配置,为在线应用提供强有力的支持


原理

Replication 总体结构

Replication的总体架构比较简单,我们直接引用社区的架构图来说明,主集群的hlog中记录了所有针对table的变更(目前的ddl不同步),通过实时读取hlog中的entry来解析变更的数据然后发送到从集群中去。


Replication 工作流程


Replication Class 简介


ReplicationSourceManagerMasterreplication线程主要管理者,负责初始化,启动或结束线程,同时也会watch主集群的ZKRS节点在有RS退出或加入是时立即failover,保证数据的无丢失。

ReplicationZooKeeper : 用于控制和管理replicationZookeeper上的一系列操作。

ReplicatioSourcereplication工作线程,负责读取,解析,发送和记录Hlog

ReplicationLogCleanner:管理Replication时的hlog

ReplicationSink: 备集群用于接收主集群的hlog entry后,分析并写入本集群

NodeFailover处理节点退出后为处理完的hlog.

ZKWatcherwatch replication对应的zk节点,并启动对应的任务。

 

Replication Zookeeper上的结构

 

Peer 节点:管理slave集群在zk上的配置。

State节点:记录replication运行的状态

Rs 节点:记录着本集群Rs中对应的hlog同步的信息,包括check point信息

Replication Failover

Hbase Replication replication时,我们通常会遇到主集群和备集群的RS预料之中或者预料之外的上线下线。在发生这种情况的时候,必须设计出一种稳定合理的并且有迭代功能的Failover处理机制来保证数据不会丢失。我们可以分别分析主从集群遇到这种情况时Failover的处理方案。

  •   主集群RS加入 :zk会迅速watchrs节点的创建,创建出新的replication source线程来处理新加入到hlog.
  •   主集群RS退出:这是最为复杂的一种情况,主要是退出的RS会有一部分的hlog没有处理完,需要稳定的shift到其他RS上,我们可以从下面三个步骤说明。
  •  集群正常工作时,ZK的状态如下:


这是1.1.1.2这台RS突然下线,ZK会第一时间watch到这个动作,最先发现的集群中的某台(1.1.1.3rs将其在Replication/rs下对应的lock住,并将其考到自己的节点之下。其他的RS1.1.1.1)发现其被lock后就不做动作。


1.1.1.3启动一个新的线程处理掉所有未被同步的hlog.保证数据不丢失。同理如果1.1.1.3此时再次下线,zk节点被迭代拷贝


  •   备集群RS加入:不影响主集群的步骤,region均匀的话客户端会自动写入到新加入到集群之中。
  •   备集群RS退出:主集群在重试几次后发现对方down机,将其加入到deadserver的列表之中,后续不会被Call


部署 


Hbase的部署详细步骤如下

 Master 集群配置文件

<property>
<name>hbase.replication</name>
<value>true</value>
<description> 打开replication功能</description>
</property>
<property>
<name>replication.source.nb.capacity</name>
<value>5000</value>
<description> 主集群每次像备集群发送的entry最大的个数,推荐5000.可根据集群规模做出适当调整,slave集群服务器如果较多,可适当增大</description>
</property>
<property>
<name>replication.source.size.capacity</name> 
<value>4194304</value> 
<description> 主集群每次像备集群发送的entry的包的最大值大小,不推荐过大</description>
</property>
<property>
<name>replication.source.ratio</name>
<value>1</value>
<description> 主集群里使用slave服务器的百分比</description>
</property>
<property>
<name>hbase.regionserver.wal.enablecompression</name>
<value>false</value>
<description> 主集群关闭hlog的压缩</description>
</property>
<property>
<name> replication.sleep.before.failover</name>
<value>5000</value>
<description> 主集群在regionserver当机后几毫秒开始执行failover</description>
</property>



 Slave 集群配置文件

<property>
<name>hbase.replication</name>
<value>true</value>
<description> 打开replication功能</description>
</property>



Master 集群配置

  •   修改好Master集群配置文件
  •   关联replication Master 和 Slave 集群,在 master hbase shell 中做以下操作 <下面的操作可以在master集群未启动时完成>
  •     [Addpeer]   hbase> add_peer '1',"zk1,zk2,zk3:2182:/hbase-prod" (zk 的地址,端口,和Slave的zk address)
  •       Start replication 标志  hbase> start_replication (add peer 和 start replication 标记是直接修改zk 上的node,所以不需要启动集群做这个动作)

Slave集群配置

  •   修改好Slave集群配置文件,并启动slave集群
  •   根据需要在Slave中创建需要同步的table,注意每个CF的KEEP_DELETED_CELLS => 'true’属性要打开来保证为写入的顺序性。
hbase> disable_peer '1'
b) 重新服务:
hbase> enable_peer '1'
c) 停止服务
hbase> stop_replication


做好上述2个集群配置后 启动Master集群,将需要同步的table 的replication scope打开。

其他一些操作:

a) 暂停服务:

暂停服务和重新服务期间的数据还是可以被同步到slave中的,而停止服务和启动服务之间的数据不会被同步。



运维经验及遇到的问题

  •   如果写入量较大,Slave 集群必须做好table 的region提前分配,防止写入全部落入1台服务器。
  •   暂停服务和重新服务期间的数据还是可以被同步到slave中的,而停止服务和启动服务之间的数据不会被同步。
  •   主集群对于同步的数据大小和个数采用默认值较大,容易导致备集群内存被压垮。建议配置减少每次同步数据的大小
  • replication.source.size.capacity4194304
  • replication.source.nb.capacity2000
  •   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节点过多不堪重负。
  •   如何初始化slave集群数据?目前我们开发了hlogrestore工具,可以distcp主集群数据或snapshot主集群数据后,将数据导入备集群,最后追上主集群的数据后开启replication.
  •  Master Push数据的方式会不会影响master的性能。基本不会,我们还开发出了一个slave拉数据的版本,根据一下测试结果我们发现,相差都不大。理由是master只是单线程顺序读hdfs上的文件并发送,消耗很低。


从主集群结果看,压力从20线程到200线程,两种replication都没对TPS和RT造成太大影响,CPUload也没有太大变化,在网络流量上会有一定的增长.

 

注:文章为原创,转载需注明出处。

阅读更多
个人分类: hbase
上一篇Hbase Scanner 排序标准
下一篇HBASE 的Hlog 如果采用压缩格式,则无法使用Seek功能
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭