hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Does hbase WAL ensures no data loss?
Date Mon, 16 Feb 2015 19:22:46 GMT
> What is hbase's philosophy in this? Does it allow some degree of data
loss?

​HBase doesn't "allow" data loss, in the sense that HBase never chooses on
its own to be less than fully durable. However, our client API does allow
users to submit mutations with different durability guarantees.
The default is to ensure the mutation has been committed to the WAL before
returning a success
​ result
​.
​T
here are other options
​ offered to sophisticated users, but those users have to ask for special
handling by setting a flag
. In general a
​user​
 should never submit mutations
​asking for them

​to ​
bypass the WAL.


On Mon, Feb 16, 2015 at 6:05 AM, Dave Latham <latham@davelink.net> wrote:

> Hi Hongbin,
>
> The WAL class is used internally to the region server.  Typically an HBase
> write operation will first call WAL.append() with the data, then later,
> after releasing locks, call WAL.sync() to ensure that the data for that
> write has been synced to be durable before returning to the client (unless
> the client instructed it to skip that step).
>
> Dave
>
> On Mon, Feb 16, 2015 at 5:21 AM, hongbin ma <mahongbin@apache.org> wrote:
>
> > hi, all
> >
> > It seems WAL.append() in hbase, the javadoc says:
> >
> > * * Append a set of edits to the WAL. The WAL is not flushed/sync'd after
> > this transaction*
> > *   * completes BUT on return this edit must have its region
> edit/sequence
> > id assigned*
> > *   * else it messes up our unification of mvcc and sequenceid.  On
> return
> > <code>key</code> will*
> > *   * have the region edit/sequence id filled in.*
> >
> > This is really confusing me, if it does does flushed every update is
> > instantly to disk, how can hbase ensures the WAL contains everything that
> > was appended? What is hbase's philosophy in this? Does it allow some
> degree
> > of data loss?
> >
> >
> > thanks
> > hongbin
> >
>

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