hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <eric.char...@u-mangate.com>
Subject Re: HBase Backups
Date Thu, 09 Jun 2011 09:19:22 GMT
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 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
View raw message