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方案对online的table实施备份(关于snapshot原理我发另一篇文章来解释)。

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

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

原理

Replication 总体结构

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

HBase replication-LMLPHP

Replication 工作流程

HBase replication-LMLPHP

Replication Class 简介

HBase replication-LMLPHP

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

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

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

ReplicationLogCleanner:管理Replication时的hlog

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

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

ZKWatcher:watch
replication对应的zk节点,并启动对应的任务。

Replication Zookeeper上的结构

HBase replication-LMLPHP

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

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

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

Replication Failover

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

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

HBase replication-LMLPHP

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

HBase replication-LMLPHP

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

HBase replication-LMLPHP

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

部署


Hbase的部署详细步骤如下

Master 集群配置文件

  1. <property>
  2. <name>hbase.replication</name>
  3. <value>true</value>
  4. <description> 打开replication功能</description>
  5. </property>
  6. <property>
  7. <name>replication.source.nb.capacity</name>
  8. <value>5000</value>
  9. <description> 主集群每次像备集群发送的entry最大的个数,推荐5000.可根据集群规模做出适当调整,slave集群服务器如果较多,可适当增大</description>
  10. </property>
  11. <property>
  12. <name>replication.source.size.capacity</name>
  13. <value>4194304</value>
  14. <description> 主集群每次像备集群发送的entry的包的最大值大小,不推荐过大</description>
  15. </property>
  16. <property>
  17. <name>replication.source.ratio</name>
  18. <value>1</value>
  19. <description> 主集群里使用slave服务器的百分比</description>
  20. </property>
  21. <property>
  22. <name>hbase.regionserver.wal.enablecompression</name>
  23. <value>false</value>
  24. <description> 主集群关闭hlog的压缩</description>
  25. </property>
  26. <property>
  27. <name> replication.sleep.before.failover</name>
  28. <value>5000</value>
  29. <description> 主集群在regionserver当机后几毫秒开始执行failover</description>
  30. </property>

 Slave 集群配置文件

  1. <property>
  2. <name>hbase.replication</name>
  3. <value>true</value>
  4. <description> 打开replication功能</description>
  5. </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上的文件并发送,消耗很低。

HBase replication-LMLPHP

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

转载自:http://blog.csdn.net/teriy/article/details/7954203

04-15 19:16