长春企业建站系统模板,公司建设网站的报告,免费做公司手机网站,重庆明建网络科技有限公司干啥的集群建备份#xff0c;它是master/slaves结构式的备份#xff0c;由master推送#xff0c;这样更容易跟踪现在备份到哪里了#xff0c;况且region server是都有自己的WAL 和HLog日志#xff0c;它就像mysql的主从备份结构一样#xff0c;只有一个日志来跟踪。一个master集…集群建备份它是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的并且不是catalogcatalog指的是.META. 和 -ROOT- 3-1这个edit然后被打上master群集的UUID当buffer写满的时候或者读完文件buffer会发到slave集群的随机的一个region server同步的收到他们的region server把edit分开一个表一个buffer当所有的edits被读完之后每一个buffer会通过HTable来flushedits里面的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/123522342.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.12651.1.1.2,60020,123456790/2/1.1.1.2,60020.1214 (Contains a position)1.1.1.2,60020.12481.1.1.2,60020.13121.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的下面多了一层lock1.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.12651.1.1.2,60020,123456790/lock2/1.1.1.2,60020.1214 (Contains a position)1.1.1.2,60020.12481.1.1.2,60020.13121.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.12481.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.14012-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/lock2/1.1.1.3,60020.1325 (Contains a position)1.1.1.3,60020.14012-1.1.1.2,60020,123456790/1.1.1.2,60020.1312 (Contains a position)原理说完了从下面说说进行这个备份操作是哪些要求吧 1hbase的大的版本要一致 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文件 propertynamehbase.replication/namevaluetrue/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