hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <tdunn...@maprtech.com>
Subject Re: HBase Backups
Date Thu, 09 Jun 2011 06:33:35 GMT
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 were able to
demonstrate the each snapshot was usable to restore hbase to the state it
had when the snapshot was taken.

On Thu, Jun 9, 2011 at 12:56 AM, Otis Gospodnetic <
otis_gospodnetic@yahoo.com> wrote:

> There is this post about HBase backup options....
> http://blog.sematext.com/2011/03/11/hbase-backup-options/ .  I hope it
> helps.
>
> Otis
> ----
> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
> Lucene ecosystem search :: http://search-lucene.com/
>
>
>
> ----- Original Message ----
> > From: Manoj Murumkar <manoj.murumkar@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" <joey@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, 2011 at 1:22 PM, Manoj Murumkar <
> manoj.murumkar@gmail.com>
> > wrote:
> > >>  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
> > >> there any suggestions to  improve the performance of this?
> > >>
> > >>  Thanks,
> > >>
> > >>  Manoj
> > >>
> > >
> > >
> > >
> > > --
> > > Joseph  Echeverria
> > > Cloudera, Inc.
> > > 443.305.9434
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message