图文精华

About云-梭伦科技»专题 › 技术学习(版主发帖区) › 大数据学习 › Hbase › 连载型› hbase 学习（二）集群间备份原理
分享

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

xioaxu790 2014-9-13 19:37:38 发表于 连载型 [显示全部楼层] 只看大图 回帖奖励 阅读模式 关闭右栏 4 12775
About云VIP帮助找工作和提升
问题导读
1、master和slave节点架构的整个过程，你是如何理解的？
2、进行备份操作都有哪些要求呢？
3、使用集群间备份的功能需要进行哪些设置？





       集群间备份，它是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是相同的。

　　下面这个是设计的结构图
1.png



　　下面我们了解一下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 , 它会有三个子节点
  1. /hbase/replication/state

  2. /hbase/replication/peers

  3. /hbase/replication/rs
复制代码



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



The Peers znode
　　这个节点下面记录着所有需要备份的集群和他们当前的备份状态，如下：
  1. /hbase/replication/peers

  2.                     /1 [Value: zk1.host.com,zk2.host.com,zk3.host.com:2181:/hbase]

  3.                     /2 [Value: zk5.host.com,zk6.host.com,zk7.host.com:2181:/hbase]
复制代码



　　peer的id是自己在add_peer时候，自己提供的，后面的value是slave集群所使用的zookeeper集群，最后是所在的znode的父节点。

　　在每一个peer节点的下面还有一个表示状态的节点
  1.  /hbase/replication/peers

  2.                     /1/peer-state [Value: ENABLED]

  3.                     /2/peer-state [Value: DISABLED]
复制代码



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

　　第一层节点记录着region server的机器名，端口号以及start code
  1. /hbase/replication/rs

  2.                     /hostname.example.org,6020,1234

  3.                     /hostname2.example.org,6020,2856
复制代码



　　下一层是需求复制的HLog的队列
  1. /hbase/replication/rs

  2.                     /hostname.example.org,6020,1234

  3.                         /1

  4.                         /2
复制代码



　　队列里面需要复制的HLog，值是已经被复制的最新的位置position
  1. /hbase/replication/rs

  2.                     /hostname.example.org,6020,1234

  3.                         /1

  4.                             23522342.23422 [VALUE: 254]

  5.                             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上的真实的文件名，“地址，端口.时间戳”

  1. /hbase/replication/rs/

  2.                       1.1.1.1,60020,123456780/

  3.                           2/

  4.                               1.1.1.1,60020.1234  (Contains a position)

  5.                               1.1.1.1,60020.1265

  6.                       1.1.1.2,60020,123456790/

  7.                           2/

  8.                               1.1.1.2,60020.1214  (Contains a position)

  9.                               1.1.1.2,60020.1248

  10.                               1.1.1.2,60020.1312

  11.                       1.1.1.3,60020,    123456630/

  12.                           2/

  13.                               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。
  1. /hbase/replication/rs/

  2.                       1.1.1.1,60020,123456780/

  3.                           2/

  4.                               1.1.1.1,60020.1234  (Contains a position)

  5.                               1.1.1.1,60020.1265

  6.                       1.1.1.2,60020,123456790/

  7.                           lock

  8.                           2/

  9.                               1.1.1.2,60020.1214  (Contains a position)

  10.                               1.1.1.2,60020.1248

  11.                               1.1.1.2,60020.1312

  12.                       1.1.1.3,60020,123456630/

  13.                           2/

  14.                               1.1.1.3,60020.1280  (Contains a position)

  15. 

  16.                           2-1.1.1.2,60020,123456790/

  17.                               1.1.1.2,60020.1214  (Contains a position)

  18.                               1.1.1.2,60020.1248

  19.                               1.1.1.2,60020.1312
复制代码



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

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

  2.                       1.1.1.1,60020,123456780/

  3.                           2/

  4.                               1.1.1.1,60020.1378  (Contains a position)

  5. 

  6.                           2-1.1.1.3,60020,123456630/

  7.                               1.1.1.3,60020.1325  (Contains a position)

  8.                               1.1.1.3,60020.1401

  9. 

  10.                           2-1.1.1.2,60020,123456790-1.1.1.3,60020,123456630/

  11.                               1.1.1.2,60020.1312  (Contains a position)

  12.                       1.1.1.3,60020,123456630/

  13.                           lock

  14.                           2/

  15.                               1.1.1.3,60020.1325  (Contains a position)

  16.                               1.1.1.3,60020.1401

  17. 

  18.                           2-1.1.1.2,60020,123456790/

  19.                               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文件
  1. <property>

  2.     <name>hbase.replication</name>

  3.     <value>true</value>

  4. </property>
复制代码


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

3、修改表的REPLICATION_SCOPE
  1. disable 'your_table'

  2. alter 'your_table', {NAME => 'family_name', REPLICATION_SCOPE => '1'}

  3. enable 'your_table'
复制代码


4、list_peers 查看一下状态

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

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

本文转载自：http://hbase.apache.org/replication.html

关注公众号，获取大数据、人工智能20套、区块链资源5阶段等资源，随时更新，获取最新技术资源
回复

使用道具 举报

自定义广告语

已有(4)人评论

跳转到指定楼层
正序浏览
anyhuayong 发表于 2014-9-15 08:41:36
楼主辛苦，谢谢
回复

使用道具 举报

chuyuan_zhou 发表于 2014-12-9 11:26:08
详尽的好帖，果断收藏
回复

使用道具 举报

chinaboy2005 发表于 2014-12-9 20:19:57

详尽的好帖，果断收藏
回复

使用道具 举报

EASONLIU 发表于 2014-12-17 10:09:50
路过，学习学习
回复

使用道具 举报

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

发表新帖
xioaxu790

金牌会员

关注

  • 851

    主题

  • 1000

    帖子

  • 108

    粉丝

TA的主题
关闭

推荐上一条 /2 下一条

关于我们· 联系我们· 加入我们· 小黑屋· 合作伙伴   

Copyright © 2001-2024 About云-梭伦科技 Powered by Discuz! X3.4 Licensed Discuz Team.

简书 / Smrz 京ICP备2020039040号 Wxb 简书网举报电话：021-34700000