To: user@hbase.apache.org
Subject: hbase backups
Hi. I am trying to figure out our disaster recovery strategy and could
certainly use some help.
we have 2 hbase clusters with data replicated across in master/slave mode.
My question is if there are any drawbacks in a model where we take snapshots
Hi. I am trying to figure out our disaster recovery strategy and could
certainly use some help.
we have 2 hbase clusters with data replicated across in master/slave mode.
My question is if there are any drawbacks in a model where we take snapshots
on the slave cluster (the replication target)
We've been working on a Backup / Restore program Hbacker
(https://github.com/rberger/hbacker) that uses the HBase Hadoop Export/Import
jobs.
Its pretty tuned to our use case (we just do appends, never delete, this allows
us to do very simple incremental backups). Its still really rough and
On Wed, Jun 8, 2011 at 11:33 PM, Ted Dunning tdunn...@maprtech.com wrote:
Otis,
We should talk some time about MapR. We did a test with Stack where we had
an hbase instance with very active writes going on. We did successive
snapshots with no interruption or pause in hbase operations and
Good news!
I suppose there's a risk of incoherent backup.
I mean, with classical sql databases, online-backups ensure that the
taken dataset can be restored in a state where all open transactions are
committed. Even if the backup takes hours, the initial backuped data is
finally updated to
Oops, sorry, I confused MapR (the company) with Map Reduce (MR, the
technology).
Time for me to update my knowledge on Hadoop ecosystem.
Tks,
- Eric
On 09/06/11 09:49, Ted Dunning wrote:
On Thu, Jun 9, 2011 at 9:12 AM, Eric Charleseric.char...@u-mangate.comwrote:
Good news!
I suppose
Hi,
We're trying to come up with right strategy for backing up HBase tables.
Assumption is that sizes of tables will not grow beyond few hundred GB.
Currently, we're employing exports (writing onto HDFS of another cluster
directly), but is taking too long (~5 hours to export ~5GB of data). Are
Can you afford some down time? If so, you could minor compact, disable
the table, distcp, and then enable the table.
-Joey
On Wed, Jun 8, 2011 at 1:22 PM, Manoj Murumkar manoj.murum...@gmail.com wrote:
Hi,
We're trying to come up with right strategy for backing up HBase tables.
Assumption is
We are trying to do this online as downtime is not an option. Good point,
nonetheless.
On Jun 8, 2011 3:48 PM, Joey Echeverria j...@cloudera.com wrote:
Can you afford some down time? If so, you could minor compact, disable
the table, distcp, and then enable the table.
-Joey
On Wed, Jun 8,
Murumkar manoj.murum...@gmail.com
To: user@hbase.apache.org
Sent: Wed, June 8, 2011 8:24:39 PM
Subject: Re: HBase Backups
We are trying to do this online as downtime is not an option. Good point,
nonetheless.
On Jun 8, 2011 3:48 PM, Joey Echeverria j...@cloudera.com wrote:
Can you afford
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/
- Original Message
From: Manoj Murumkar manoj.murum...@gmail.com
To: user@hbase.apache.org
Sent: Wed, June 8, 2011 8:24:39 PM
Subject: Re: HBase Backups
We
Hi guys,
More and more data in our company is moving from mysql tables to hbase
and more and more worried I am about the no backups situation with
that data. I've started looking for possible solutions to backup the
data and found two major options:
1) distcp of /hbase directory somewhere
2)
If you are asking about current solutions, then yes you can distcp
but I would consider that a last resort solution for the reasons you
described (yes, you could end up with an inconsistent state that
requires manual fixing). Also it completely bypasses row locks.
Another choice is using the
13 matches
Mail list logo
