HBase中的备份和故障恢复方法

本文将对Apache HBase可用的数据备份机制和大量数据的故障恢复/容灾机制做简要介绍。

随着HBase在重要的商业系统中应用的大量添加，很多企业须要通过对它们的HBase集群建立健壮的备份和故障恢复（backup and disaster recovery, BDR）机制来保证它们的企业（数据）资产。

HBase和Apache Hadoop系统提供了很多内置的机制，能够高速而轻松的完毕PB级数据的备份和恢复工作。

在这篇文章中，你将会对在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
• Replication
• Export
• CopyTable
• HTable API
• Offline backup of HDFS data

以下的表格提供了一个关于这些方法的高速比較。具体的细节在以下再具体描写叙述。

Snapshots（快照）

HBase快照功能丰富。有非常多特征，而且创建时不须要关闭集群。

关于snapshot在文章《apache hbase snapshot介绍》中有更具体的介绍。

快照能通过在HDFS中创建一个和unix硬链接同样的存储文件，简单捕捉你的hbase表的某一时刻的信息（图1）。这些快照在几秒内就能够完毕，差点儿对整个集群没有不论什么性能影响。

而且。它仅仅占用一个微不足道的空间。除了在metadata文件里存储的极少文件夹数据，你的数据不会冗余，快照同意你的系统回滚到（创建快照）那个时刻。当然。你须要恢复快照。

图1

通过在HBase shell中执行例如以下命令来创建一个表的快照：

hbase(main):001:0>  snapshot 'myTable', 'MySnapShot'

在运行这条命令之后，你将发如今hdfs中有一些小的数据文件。

在 /hbase/.snapshot/myTable (CDH4) 或者hbase/.hbase-snapshots (Apache 0.94.6.1)，这些文件里存储着快照信息。

想要恢复数据仅仅须要运行在shell中运行例如以下命令：

hbase(main):002:0>  disable 'myTable'
hbase(main):003:0>  restore_snapshot 'MySnapShot'
hbase(main):004:0>  enable 'myTable'

正如你看到的。恢复快照须要对表进行离线操作。

一旦恢复快照。那不论什么在快照时刻之后做的添加/更新数据都会丢失。

假设你的业务需求是这种：你必须有数据的异地备份，你能够用exportSnapshot命令赋值一个表的数据到你的本地HDFS或者你选择的远程HDFS中。

快照是你的表在某一个时刻的完整图像。眼下没有增量快照功能可用。

HBase复制（HBase Relication）

HBase赋值是另外一个负载较轻的备份工具。

文章《HBase复制概述》有对它的具体描写叙述。

总的来说，赋值被定义为列簇级别，能够工作在后台而且保证全部的编辑操作在集群复制链之间的同步。

复制有三种模式：主->从(master->slave)。主<->主(master<->master)和循环（cyclic）。这样的方法给你灵活的从随意数据中心获取数据而且确保它能获得在其它数据中心的全部副本。

在一个数据中心发生灾难性故障的情况下，client应用程序能够利用DNS工具，重定向到另外一个备用位置。

复制是一个强大的。容错的过程。

它提供了“终于一致性”，意味着在不论什么时刻，近期对一个表的编辑可能无法应用到该表的全部副本。可是终于可以确保一致。

注：对于一个存在的表，你须要通过本文描写叙述的其它方法，手工的拷贝源表到目的表。

复制只在你启动它之后才对新的写/编辑操作有效。

表2 集群复制架构图

导出（Export）

HBase的导出工具是一个内置的有用功能。它使数据非常easy从hbase表导入HDFS文件夹下的SequenceFiles文件。

它创造了一个map reduce任务。通过一系列HBase API来调用集群，获取指定表格的每一行数据。而且将数据写入指定的HDFS文件夹中。这个工具对集群来讲是性能密集的，由于它使用了mapreduce和HBase clientAPI。

可是它的功能丰富。支持制定版本号或日期范围。支持数据的筛选，从而使增量备份可用。

以下是一个导出命令的简单样例：

hbase org.apache.hadoop.hbase.mapreduce.Export <tablename> <outputdir>

一旦你的表导出了，你就能够复制生成的数据文件到你想存储的不论什么地方（比方异地/离线集群存储）。你能够运行一个远程的HDFS集群/文件夹作为命令的输出文件夹參数，这样数据将会直接被导出到远程集群。使用这种方法须要网络。所以你应该确保到远程集群的网络连接是否可靠以及高速。

拷贝表（CopyTable）

拷贝表功能在文章《使用CopyTable在线备份HBase》中有具体描写叙述，可是这里做了主要的总结。和导出功能类似，拷贝表也使用HBase API创建了一个mapreduce任务。以便从源表读取数据。

不同的地方是拷贝表的输出是hbase中的还有一个表，这个表能够在本地集群，也能够在远程集群。

一个简单的样例例如以下：

hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=testCopy test

这个命令将会拷贝名为test的表到集群中的另外一个表testCopy。

请注意，这里有一个明显的性能开销，它使用独立的“puts”操作来逐行的写入数据到目的表。假设你的表很大。拷贝表将会导致目标region server上的memstore被填满。会引起flush操作并终于导致合并操作的产生，会有垃圾收集操作等等。

此外，你必须考虑到在HBase上执行mapreduce任务所带来的性能影响。对于大型的数据集，这样的方法的效果可能不太理想。

HBase API（比方作为一个java应用）

因为总是这样使用hadoop。你能够使用公用的api写自己定制的client应用程序来直接查询表格。你也能够通过mapreduce任务的批量处理优势，或者自己设计的其它手段。然而，这种方法须要对hadoop开发以及因此对生产集群带来的影响有深入的理解。

离线备份原生的HDFS数据（Offline Backup of Raw HDFS Data）

最强力的备份机制。也是破坏性最大的一个。

涉及到最大的数据占用空间。

你能够干净的关闭你的HBase集群而且手工的在HDFS上拷贝数据。由于HBase已经关闭，所以能确保全部的数据已经被持久化到HDFS上的HFile文件里，你也将能获得一个最准确的数据副本。

可是，增量的数据差点儿不能再获得，你将无法确定哪些数据发生了变化。

同一时候也须要注意。恢复你的数据将须要一个离线的元数据由于.META.表将包括在修复时可能无效的信息。这样的方法须要一个高速的。可信赖的网络来传输异地的数据，假设须要在稍后恢复它的话。

因为这些原因。Cloudera很不鼓舞在HBase中这样的备份方法。

故障恢复（Disaster Recory）

HBase被设计为一个非常能容忍错误的分布式系统，如果硬件失败非常频繁。在HBase中的故障恢复通常有下面几种形式：

• 在数据中心级别的灾难性故障，须要切换到备份位置；
• 须要恢复因为用户错误或者意外删除的数据的之前一个拷贝；
• 出于审计目的，恢复实时点数据拷贝的能力

正如其它的故障恢复计划，业务须要驱动这你怎样架构而且投入多少金钱。一旦你确定了你将要选择的备份方案。恢复将有下面几种类型：

• 故障转移到备份集群
• 导入表/恢复快照
• 指向HBase在备份位置的根文件夹

假设你的备份策略是这种，你复制你的HBase数据在不同数据中心的备份集群，故障转移将变得简单。仅须要使用DNS技术。转移你的应用程序。

请记住。假设你打算同意数据在停运时写入你的备份集群，那你须要确保在停运结束后。数据能够回到主机群。主<->主或循环的复制架构能自己主动处理这个过程。但对于一个主从结构来讲。你就须要手动进行干预了。

你也能够在故障时通过简单的改动hbase-site.xml的 hbase.root.dir属性来更改hbase根文件夹，可是这是最不理想的还原选项。由于你复制完数据返回生产集群时，正如之前提到的。可能会发现.META是不同步的。

总结

综上所述。从某种损失或中断中恢复数据须要一个精心设计的BDR计划。

强烈建议你彻底明确你的业务需求，然后明确数据准确度/可用性以及故障恢复的最大时间。有了这些知识，你才干更好的选择满足这些需求的工具。

选择工具不过个開始。你应该对你的BDR策略进行大规模測试，以确保它的在你的基础设施下的功能。

而且，你应该是很熟悉全部的故障恢复步骤。

（翻译的不是非常好，请如有错误之处，请见谅。）

原文地址：http://blog.cloudera.com/blog/2013/11/approaches-to-backup-and-disaster-recovery-in-hbase/

转载请注明出处：http://blog.csdn.net/iAm333