标签：比较 基于 复杂 主从 .com 文件 font 分布 存储系统
在这篇文章中，你将会对在HBase中可用的数据备份机制有一个高层次的简要了解，并且知道多种数据恢复/容灾机制。在阅读了这篇文章之后，你应该能对你的业务需要那种BDR策略有了自己的判断。你也应该明白各种机制各自的优缺点（适用于CDH 4.3.0/HBase 0.94.6及更高版本）。
备份
HBase是一个基于LSM树（log-structured merge-tree）的分布式数据存储系统，它使用复杂的内部机制确保数据准确性、一致性、多版本等。因此，你如何获取数十个region server在HDFS和内存中的存储的众多HFile文件、WALs（Write-Ahead-Logs）的一致的数据备份？
让我们从最小的破坏性，最小的数据占用空间，最小的性能要求机制和工作方式到最具破坏性的逐一讲述：
下面的表格提供了一个关于这些方法的快速比较，具体的细节在下面再详细描述。
Snapshots（快照）
HBase快照功能丰富，有很多特征，并且创建时不需要关闭集群。关于snapshot在文章《apache hbase snapshot介绍》中有更详细的介绍。
快照能通过在HDFS中创建一个和unix硬链接相同的存储文件，简单捕捉你的hbase表的某一时刻的信息（图1）。这些快照在几秒内就可以完成，几乎对整个集群没有任何性能影响。并且，它只占用一个微不足道的空间。除了在metadata文件中存储的极少目录数据，你的数据不会冗余，快照允许你的系统回滚到（创建快照）那个时刻，当然，你需要恢复快照。
图1
通过在HBase shell中运行如下命令来创建一个表的快照：
快照是你的表在某一个时刻的完整图像，目前没有增量快照功能可用。
HBase复制（HBase Relication）
HBase赋值是另外一个负载较轻的备份工具。文章《HBase复制概述》有对它的详细描述。总的来说，赋值被定义为列簇级别，可以工作在后台并且保证所有的编辑操作在集群复制链之间的同步。
复制有三种模式：主->从(master->slave)，主<->主(master<->master)和循环（cyclic）。这种方法给你灵活的从任意数据中心获取数据并且确保它能获得在其他数据中心的所有副本。在一个数据中心发生灾难性故障的情况下，客户端应用程序可以利用DNS工具，重定向到另外一个备用位置。
复制是一个强大的，容错的过程。它提供了“最终一致性”，意味着在任何时刻，最近对一个表的编辑可能无法应用到该表的所有副本，但是最终能够确保一致。
注：对于一个存在的表，你需要通过本文描述的其他方法，手工的拷贝源表到目的表。复制仅仅在你启动它之后才对新的写/编辑操作有效。
表2 集群复制架构图
导出（Export）
HBase的导出工具是一个内置的实用功能，它使数据很容易从hbase表导入HDFS目录下的SequenceFiles文件。它创造了一个 map reduce任务，通过一系列HBase API来调用集群，获取指定表格的每一行数据，并且将数据写入指定的HDFS目录中。这个工具对集群来讲是性能密集的，因为它使用了mapreduce和 HBase 客户端API。但是它的功能丰富，支持制定版本或日期范围，支持数据的筛选，从而使增量备份可用。
下面是一个导出命令的简单例子：
拷贝表（CopyTable）
拷贝表功能在文章《使用CopyTable在线备份HBase》中有详细描述，但是这里做了基本的总结。和导出功能类似，拷贝表也使用HBase API创建了一个mapreduce任务，以便从源表读取数据。不同的地方是拷贝表的输出是hbase中的另一个表，这个表可以在本地集群，也可以在远程集群。
一个简单的例子如下：
请注意，这里有一个明显的性能开销，它使用独立的“puts”操作来逐行的写入数据到目的表。如果你的表非常大，拷贝表将会导致目标region server上的memstore被填满，会引起flush操作并最终导致合并操作的产生，会有垃圾收集操作等等。
此外，你必须考虑到在HBase上运行mapreduce任务所带来的性能影响。对于大型的数据集，这种方法的效果可能不太理想。
HBase API（比如作为一个java应用）
由于总是这样使用hadoop，你可以使用公用的api写自己定制的客户端应用程序来直接查询表格。你也可以通过mapreduce任务的批量处理优势，或者自己设计的其他手段。然而，这个方法需要对hadoop开发以及因此对生产集群带来的影响有深入的理解。
离线备份原生的HDFS数据（Offline Backup of Raw HDFS Data）
最强力的备份机制，也是破坏性最大的一个。涉及到最大的数据占用空间。你可以干净的关闭你的HBase集群并且手工的在HDFS上拷贝数据。因为 HBase已经关闭，所以能确保所有的数据已经被持久化到HDFS上的HFile文件中，你也将能获得一个最准确的数据副本。但是，增量的数据几乎不能再获得，你将无法确定哪些数据发生了变化。
同时也需要注意，恢复你的数据将需要一个离线的元数据因为.META.表将包含在修复时可能无效的信息。这种方法需要一个快速的，可信赖的网络来传输异地的数据，如果需要在稍后恢复它的话。
由于这些原因，Cloudera非常不鼓励在HBase中这种备份方法。
故障恢复（Disaster Recory）
HBase被设计为一个非常能容忍错误的分布式系统，假设硬件失败很频繁。在HBase中的故障恢复通常有以下几种形式：
正如其他的故障恢复计划，业务需要驱动这你如何架构并且投入多少金钱。一旦你确定了你将要选择的备份方案，恢复将有以下几种类型：
如果你的备份策略是这样的，你复制你的HBase数据在不同数据中心的备份集群，故障转移将变得简单，仅需要使用DNS技术，转移你的应用程序。
请记住，如果你打算允许数据在停运时写入你的备份集群，那你需要确保在停运结束后，数据可以回到主机群。主<->主或循环的复制架构能自动处理这个过程，但对于一个主从结构来讲，你就需要手动进行干预了。
你也可以在故障时通过简单的修改hbase-site.xml的 hbase.root.dir属性来更改hbase根目录，但是这是最不理想的还原选项，因为你复制完数据返回生产集群时，正如之前提到的，可能会发现.META是不同步的。
标签：比较 基于 复杂 主从 .com 文件 font 分布 存储系统
原文地址：http://www.cnblogs.com/charlist/p/7064045.html
