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 07:49:27 GMT
On Thu, Jun 9, 2011 at 9:12 AM, Eric Charles <eric.charles@u-mangate.com>wrote:

> Good news!
>
> I suppose there's a risk of "incoherent" backup.
>

There would be but we spent a ton of time making that not so.  And the hbase
devs have done a bunch of work making sure that the WAL works right.


> 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 reflect the last transactions.
>

The snapshot I mentioned is atomic.  Really.  That means that it is
equivalent to having the same state as if all of the machines lost power
simultaneously.  Since hbase is not crash safe, the snapshot is, by
definition and intent, restartable.


> With the MR process you describe, I guess we don't have this guarantee.
> Let's say, if an insert is achieved in Table_A and Table_A snapshot is
> already taken by the MR, we could have a Table_B snapshot that mention this
> last entry.
>

MapR.  Not Map Reduce.  See http://mapr.com/ for some sparse information.
 Come to hadoop summit for more information (see
http://developer.yahoo.com/events/hadoopsummit2011/agenda.html#11 )


>
> This is why I understand this process, even if fast, as a best-effort to
> backup the datas.
>

I don't think you are quite clear on what is happening.


>
> Please correct me if I'm wrong.
>

Done!

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