> 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 <lat...@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 <mahong...@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 > > >
