hbase 学习(十三)集群间备份原理

  • 时间:
  • 浏览:1
  • 来源:大发彩票快三—大发彩票app

1)当客户端通过api发送Put、Delete里能 ICV到region server,有有哪些KeyValue被转添加WALEdit,什儿 过程会被replication检测到,每有两个 设置了replication的列族,会把scope添加到edit的日志,里能 追加到WAL中,并被应用到MemStore中。

集群建备份,它是master/slaves行态式的备份,由master推送,曾经更容易跟踪现在备份到哪里了,况且region server是是否买车人的WAL 和HLog日志,它就像mysql的主从备份行态一样,不里能 有两个 日志来跟踪。有两个 master集群里能 向多个slave集群推送,收到推送的集群会覆盖它本地的edits日志。

3-2)这顶端,里能 slave的region server如此响应,master的region server会停止等待,里能 重试,里能 目标的region server还是不可用,它会重新确定别的slave的region server去发送有有哪些buffer。

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

peer的id是买车人在add_peer曾经,买车人提供的,顶端的value是slave集群所使用的zookeeper集群,最后是所在的znode的父节点。

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

3、修改表的REPLICATION_SCOPE

下面什儿 是设计的行态图:

输入什儿 命令,查看它的具体用法,里能 添加

(6)集群间的zookeeper.znode.parent不里能 相同

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

有两个 有两个region server集群正在和有两个 peer id为2的集群进行备份,每个region server下面是是否两个 队列

(2)独立部署的zookeeper集群

2、add_peer

什儿 节点下面记录着所有不里能 备份的集群和我们都我们都我们都都都当前的备份情况,如下:

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

1.1.1.1把1.1.1.3的未完成事业给接过了过来,就是 我们都我们都我们都都都看到1.1.1.1下面有个三手货和2个二手货。。。

rs的节点下面包括了群克隆的region server以及需求群克隆的HLog的队列,看图就知道啦!

在每有两个 peer节点的下面还有有两个 表示情况的节点:

0.90.1 里能 向0.90.0推送里能 0.90.1不里能 向0.89.2060 725推送

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

4、list_peers 查看一下情况

一起WALs会被回滚,里能 保存有两个 队列在zookeeper当中,有有哪些被region server存档的Logs会更新我们都我们都我们都是是否群克隆tcp连接中的内存中的queue的地址。

现在让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。

state节点是记录是是否里能 进行备份的,它顶端记录什儿 有两个 boolean值,true里能 false,它是由hbase.replication决定的,同事它会在ReplicationZookeeper当中缓存,它里能 里能 在shell中执行了stop_replication而改变

什儿 备份操作是异步的,这愿因着,有曾经我们都我们都我们都都都的连接里能 是断开的,master的变化无需马上反应到slave当中。备份个格式在设计上是和mysql的statement-based replication是一样的,完整版的WALEdits(多种来自Delete和Put的Cell单元)为了保持原子性,会一次性提交。

集群之间备份的网址,说明我们都我们都我们都是是否为什工作的:

4-2)当目标集群可用了,master的region server会群克隆积压的日志。

里能 1.1.1.3又买车人倒腾了一会儿,假设它也挂了,最后的行态会是曾经

1)确定哪个region server去群克隆

当master节点准备好备份曾经,它首好难通过slave集群的zookeeper,里能 查看我们都我们都我们都都都的rs的节点下面有2个可用的rs,里能 随机确定我们都我们都我们都都都中的一每项,默认是10%,里能 有60 个机器说说,会确定1两个机器去发送。什儿 曾经是有有两个 watcher在监视着slave集群的rs下面的变化,里能 节点处在了变化,它会通知master节点的region server重发。

下一层是需求群克隆的HLog的队列:

5、备份完成曾经怎么进行数据校验,VerifyReplication就是 专门来避免什儿 校验的。我们都我们都我们都都都不里能 提供peer的id还有表名,verifyrep是它的简称,要用hadoop jar来运行。

1、修改hbase-site.xml文件

(4)多个slave集群说说,要0.92以上版本

4-1)回到master的region server上,当前WAL的位移offset里能 被注册到了zookeeper顶端。

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

(3)集群间的备份的表名和列族是否一致

(1)hbase的大的版本要一致

 要使用什儿 集群建备份的功里能 不能 先进行以下的设置:

队列顶端不里能 群克隆的HLog,值是里能 被群克隆的最新的位置position。

下面是什儿 具体的操作:

3-1)什儿 edit里能 被打上master群集的UUID,当buffer写满的曾经里能 读完文件,buffer会发到slave集群的随机的有两个 region server同步的,收到我们都我们都我们都都都的region server把edit分开,有两个 表有两个 buffer,当所有的edits被读完曾经,每有两个 buffer会通过HTable来flush,edits顶端的master集群的UUID被应用到了备份节点,以此里能 进行循环备份。

HLogs是region server备份的基础,我们都我们都我们都都是是否进行备份时不里能 保处在hdfs上,每个region server从它不里能 的最老的日志曾经刚开始英文英文英文进行备份,里能 把当前的指针保处在zookeeper当中来简化错误恢复,什儿 位置对于每有两个 slave 集群是不同的,里能 对于同有两个 队列的HLogs是相同的。

2)错误恢复,直接来个实际的例子

(5)集群间里能 互相访问

原理说完了,从下面说说进行什儿 备份操作是有哪些要求吧

2)在曾经tcp连接当中,edit被从log当中读取来,里能 不里能 里能 备份的KeyValues(列族为scoped为GLOBAL的,里能 是否catalog,catalog指的是.META. 和 -ROOT-)