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来解析变更的数据然后发送到从集群中去。
Replication 工作流程
Replication Class 简介
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上的结构
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的状态如下：
这是1.1.1.2这台RS突然下线，ZK会第一时间watch到这个动作，最先发现的集群中的某台（1.1.1.3）rs将其在Replication/rs下对应的lock住，并将其考到自己的节点之下。其他的RS（1.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也没有太大变化，在网络流量上会有一定的增长.
转载自：http://blog.csdn.net/teriy/article/details/7954203