hbase 学习（十三）集群间备份原理

集群建备份，它是master/slaves结构式的备份，由master推送，这样更容易跟踪现在备份到哪里了，况且region server是都有自己的WAL 和HLog日志，它就像mysql的主从备份结构一样，只有一个日志来跟踪。一个master集群可以向多个slave集群推送，收到推送的集群会覆盖它本地的edits日志。

这个备份操作是异步的，这意味着，有时候他们的连接可能是断开的，master的变化不会马上反应到slave当中。备份个格式在设计上是和mysql的statement-based replication是一样的，全部的WALEdits（多种来自Delete和Put的Cell单元）为了保持原子性，会一次性提交。

HLogs是region server备份的基础，当他们要进行备份时必须保存在hdfs上，每个region server从它需要的最老的日志开始进行备份，并且把当前的指针保存在zookeeper当中来简化错误恢复，这个位置对于每一个slave 集群是不同的，但是对于同一个队列的HLogs是相同的。

下面这个是设计的结构图：

下面我们了解一下master和一个slave节点的整个过程。

1）当客户端通过api发送Put、Delete或者ICV到region server，这些KeyValue被转换成WALEdit，这个过程会被replication检测到，每一个设置了replication的列族，会把scope添加到edit的日志，然后追加到WAL中，并被应用到MemStore中。

2）在另一个线程当中，edit被从log当中读取来，并且只有可以备份的KeyValues（列族为scoped为GLOBAL的，并且不是catalog，catalog指的是.META. 和 -ROOT-）

3-1）这个edit然后被打上master群集的UUID，当buffer写满的时候或者读完文件，buffer会发到slave集群的随机的一个region server同步的，收到他们的region server把edit分开，一个表一个buffer，当所有的edits被读完之后，每一个buffer会通过HTable来flush，edits里面的master集群的UUID被应用到了备份节点，以此可以进行循环备份。

4-1）回到master的region server上，当前WAL的位移offset已经被注册到了zookeeper上面。

3-2）这里面，如果slave的region server没有响应，master的region server会停止等待，并且重试，如果目标的region server还是不可用，它会重新选择别的slave的region server去发送那些buffer。

同时WALs会被回滚，并且保存一个队列在zookeeper当中，那些被region server存档的Logs会更新他们在复制线程中的内存中的queue的地址。

4-2）当目标集群可用了，master的region server会复制积压的日志。

下面是一些具体的操作：

假设zookeeper当中的节点是/hbase/replication , 它会有三个子节点。

/hbase/replication/state
/hbase/replication/peers
/hbase/replication/rs

The State znode

state节点是记录是否可以进行备份的，它里面记录这个一个boolean值，true或者false，它是由hbase.replication决定的，同事它会在ReplicationZookeeper当中缓存，它还会因为在shell中执行了stop_replication而改变。

/hbase/replication/state [VALUE: true]

The Peers znode

这个节点下面记录着所有需要备份的集群和他们当前的备份状态，如下：

/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的id是自己在add_peer时候，自己提供的，后面的value是slave集群所使用的zookeeper集群，最后是所在的znode的父节点。

在每一个peer节点的下面还有一个表示状态的节点：

/hbase/replication/peers
                    /1/peer-state [Value: ENABLED]
                    /2/peer-state [Value: DISABLED]

The RS znode

rs的节点下面包括了复制的region server以及需求复制的HLog的队列，看图就知道啦！

第一层节点记录着region server的机器名，端口号以及start code。

/hbase/replication/rs
                    /hostname.example.org,6020,1234
                    /hostname2.example.org,6020,2856

下一层是需求复制的HLog的队列：

/hbase/replication/rs
                    /hostname.example.org,6020,1234
                        /1
                        /2

队列里面需要复制的HLog，值是已经被复制的最新的位置position。

/hbase/replication/rs
                    /hostname.example.org,6020,1234
                        /1
                            23522342.23422 [VALUE: 254]
                            12340993.22342 [VALUE: 0]

过程是上述的过程，下面展开讲一下具体的细节。

1）选择哪个region server去复制

当master节点准备好备份之后，它首先要通过slave集群的zookeeper，然后查看他们的rs的节点下面有多少可用的rs，然后随机选择他们中的一部分，默认是10%，如果有150个机器的话，会选择15个机器去发送。这个时候是有一个watcher在监视着slave集群的rs下面的变化，如果节点发生了变化，它会通知master节点的region server重发。

2）错误恢复，直接来个实际的例子

一个有3个region server集群正在和一个peer id为2的集群进行备份，每个region server下面都有一个队列

队列中的每个znode都是hdfs上的真实的文件名，“地址，端口.时间戳”。

/hbase/replication/rs/
                      1.1.1.1,60020,123456780/
                          2/
                              1.1.1.1,60020.1234  (Contains a position)
                              1.1.1.1,60020.1265
                      1.1.1.2,60020,123456790/
                          2/
                              1.1.1.2,60020.1214  (Contains a position)
                              1.1.1.2,60020.1248
                              1.1.1.2,60020.1312
                      1.1.1.3,60020,    123456630/
                          2/
                              1.1.1.3,60020.1280  (Contains a position)

现在让1.1.1.2的zookeeper丢失session，观察者会创建一个lock，这个时候1.1.1.3完成了，它会把1.1.1.2的给接手过来，在自己的znode下面创建一个新的znode，并且加上dead的server的名称，就像下面这样子，原来的1.1.1.2的下面多了一层lock，1.1.1.3下面多了一个，和它原始的状态也不一样，前面多了个2。

/hbase/replication/rs/
                      1.1.1.1,60020,123456780/
                          2/
                              1.1.1.1,60020.1234  (Contains a position)
                              1.1.1.1,60020.1265
                      1.1.1.2,60020,123456790/
                          lock
                          2/
                              1.1.1.2,60020.1214  (Contains a position)
                              1.1.1.2,60020.1248
                              1.1.1.2,60020.1312
                      1.1.1.3,60020,123456630/
                          2/
                              1.1.1.3,60020.1280  (Contains a position)

                          2-1.1.1.2,60020,123456790/
                              1.1.1.2,60020.1214  (Contains a position)
                              1.1.1.2,60020.1248
                              1.1.1.2,60020.1312

然后1.1.1.3又自己倒腾了一会儿，假设它也挂了，最后的形态会是这样

1.1.1.1把1.1.1.3的未完成事业给接过了过来，所以我们看到1.1.1.1下面有个三手货和几个二手货。。。

/hbase/replication/rs/
                      1.1.1.1,60020,123456780/
                          2/
                              1.1.1.1,60020.1378  (Contains a position)

                          2-1.1.1.3,60020,123456630/
                              1.1.1.3,60020.1325  (Contains a position)
                              1.1.1.3,60020.1401

                          2-1.1.1.2,60020,123456790-1.1.1.3,60020,123456630/
                              1.1.1.2,60020.1312  (Contains a position)
                      1.1.1.3,60020,123456630/
                          lock
                          2/
                              1.1.1.3,60020.1325  (Contains a position)
                              1.1.1.3,60020.1401

                          2-1.1.1.2,60020,123456790/
                              1.1.1.2,60020.1312  (Contains a position)

原理说完了，从下面说说进行这个备份操作是哪些要求吧

（1）hbase的大的版本要一致

0.90.1 可以向0.90.0推送但是0.90.1不可以向0.89.20100725推送

（2）独立部署的zookeeper集群

（3）集群间的备份的表名和列族都要一致

（4）多个slave集群的话，要0.92以上版本

（5）集群间可以互相访问

（6）集群间的zookeeper.znode.parent不能相同

 要使用这个集群建备份的功能需要先进行以下的设置：

1、修改hbase-site.xml文件

<property>
    <name>hbase.replication</name>
    <value>true</value>
</property>

2、add_peer

输入这个命令，查看它的具体用法，然后添加

3、修改表的REPLICATION_SCOPE

disable 'your_table'
alter 'your_table', {NAME => 'family_name', REPLICATION_SCOPE => '1'}
enable 'your_table'

4、list_peers 查看一下状态

5、备份完成之后如何进行数据校验，VerifyReplication就是专门来处理这个校验的。我们需要提供peer的id还有表名，verifyrep是它的简称，要用hadoop jar来运行。

集群之间备份的网址，说明他们是怎么工作的：

http://hbase.apache.org/replication.html

时间： 2024-10-22 23:39:48

hbase 学习（十三）集群间备份原理的相关文章

E-MapReduce的HBase集群间迁移

HBase集群间数据迁移 0. 前置 HBase集群 HDFS Cluster-A hdfs:/A Cluster-B hdfs:/B Cluster-A集群数据迁移到Cluster-B 1. Export/Import 将Cluster-A中HBase表export到Cluster-B的HDFS中,然后在Cluster-B中使用import导入HBase a) Cluster-A和Cluster-B网络通 Cluster-B中建好相关迁移的表 hbase(main):001:0>create

Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之ORACLE集群概念和原理（二）

ORACLE集群概念和原理(二) Oracle集群概念和原理 Oracle的三种高可用集群方案 1 RAC(Real Application Clusters)                         多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储.这个系统可以容忍单机/或是多机失败.不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内.如果机房出故障,比如网络不通,那就坏了.所以仅仅用RAC

HBase高可用集群运维实践

随着越来越多的业务选择HBase作为存储引擎,对HBase的可用性要求也越来越高,对于HBase的运维也提出了新的挑战.目前运维集群超过30+,而且接入的业务类型繁多,对于性能要求也不完全一样,这是今年面临的问题.从15年开始,结合京东的业务情况,基于大数据平台,实现用户接入使用全流程自动化.而今年,我们主要从集群层面上提升集群可用性. 1.控制隔离--rsgroup 在94版本中,经常困扰我们的一个问题就是集群上的某些机器会因为某些用户的不恰当操作,例如热点问题,大量的scan操作等导致机器上

《Hadoop实战手册》一1.3 使用distcp实现集群间数据复制

1.3 使用distcp实现集群间数据复制 Hadoop分布式复制(distcp)是Hadoop集群间复制大量数据的高效工具.distcp是通过启动MapReduce实现数据复制的.使用MapReduce的好处包含可并行性.高容错性.作业恢复.日志记录.进度汇报等.Hadoop分布式复制(distcp)对在开发集群环境.研究集群环境和生产集群环境之间进行数据复制十分有用. 准备工作首先必须保证复制源和复制目的地能够互相访问. 最好关闭复制源集群map任务的推测机制,可以在配置文件mapred-s

redis-怎么实现spring Security实现集群间共享session？？？

问题描述 怎么实现spring Security实现集群间共享session??? 2C spring security中,怎么把共享的session存入到redis中去? protected void configure(HttpSecurity http) throws Exception { http .sessionManagement() .maximumSessions(32) .sessionRegistry(sessionRegistry); 这里面会话注册表sessionReg

hadoop集群间数据迁移

问题描述 hadoop集群间数据迁移 bin/hadoop distcp hftp://master:50070/user/wp hdfs://ns1/user/ hadoop集群间数据迁移org.apache.hadoop.tools.mapred.RetriableFileCopyCommand$CopyReadException: java.net.SocketTimeoutException: connect timed out

互联网+时代的电子政务系统 双机集群及备份方案成标配

  作为"不下班的网上政府",电子政务系统在互联网+政务的浪潮中,已经成为各级政府提升网络资源共享水平.提高政务处理效率以及民众满意度.推动职能转变的建设重点.浪潮作为备受政府信任的硬件厂商,利用双机集群及备份方案推动电子政务系统数据中心的建设,给予电子政务办公系统业务连续+数据安全双重保障. 政府"特烦恼":如何确保电子政务系统稳定高效运行? 对于大型的电子政务系统来说,内网数据中心是一个至关重要的信息化基础设施,其承担着内网办公.管理.协调.监督和特殊办公的应用

Tomcat集群Cluster实现原理剖析

在上一篇文章中简要介绍了如何通过简单的配置来实现tomcat集群,本文意在介绍对tomcat集群进行更深入详细的配置以满足特定需求.        对于WEB应用集群的技术实现而言,最大的难点就是如何能在集群中的多个节点之间保持数据的一致性,会话(Session)信息是这些数据中最重要的一块.     要实现这一点,大体上有两种方式,           一种是把所有Session数据放到一台服务器上或者数据库中,集群中的所有节点通过访问这台Session服务器来获取数据:          

如何实现hadoop集群间通信和作业调度？

问题描述 有多个hadoop集群,各集群的hadoop版本一致,这几个hadoop集群可能分布在不同地域.1.要求能在其中一个集群的管理端看到其他集群的节点信息,比如hdfs的文件目录信息等.2.要求在其中任意节点下发MR(或hive,spark)作业,在数据所在的集群执行此MR(或hive,spark)作业,也就是在数据所在集群执行作业.请各位帮忙提供一些建议或者解决思路,谢谢啦! 解决方案 解决方案二:考虑hadoop的federation,做适当配置修改.