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

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

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

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

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

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

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

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

•       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 集群配置文件

 Slave 集群配置文件

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中的，而停止服务和启动服务之间的数据不会被同步。