hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: does failure of write to memstore has any impact on response code from hbase
Date Fri, 09 Aug 2019 02:44:24 GMT
On Thu, Aug 8, 2019 at 11:49 AM Jean-Marc Spaggiari <jean-marc@spaggiari.org>
wrote:

> Don't we first write to WAL and then memstore? Getting confused here,
> sorry.
>
>
You are right JMS. IIRC, Udai is correct for older versions of HBase; the
memstore update would get rolled back if the concurrent WAL write failed.
S



> JMS
>
> Le mer. 7 août 2019 13 h 22, Udai Bhan Kashyap (BLOOMBERG/ PRINCETON) <
> ukashyap1@bloomberg.net> a écrit :
>
> > memstore is written first and if write(s) to WAL fails, they are rolled
> > back.
> >
> > From: dev@hbase.apache.org At: 08/07/19 13:15:27To:
> dev@hbase.apache.org
> > Subject: Re: does failure of write to memstore has any impact on response
> > code from hbase
> >
> > On Mon, Aug 5, 2019 at 9:36 PM Maneesh Bhunwal <
> maneesh.bhunwal@gmail.com>
> > wrote:
> >
> > > Hi Team,
> > >
> > > First fo all thanks for the awesome product.
> > >
> > > Can you please help me with how will application behave when write to
> > > memstore fails but write to WAL has succeeded already,will we return
> > > success to the user or failure?
> > >
> > > Failure. Client will get an exception that varies dependent on failure
> > type.
> >
> >
> > > Also what if db crashes after writing to WAL, when db will come up
> after
> > > crash, it will assume that whatever is there in WAL has been
> replicated,
> > > but that may not be the case.
> > >
> > >
> > DB does not make progress until the write to the DB has been sync'd
> (which
> > means the edit has been replicated). So on crash, the WAL will be
> replayed.
> > The edit that was written to the WAL but not to the memstore on which the
> > client received an exception, will perpetuate.
> >
> > S
> >
> >
> > > Can you please help me with the above?
> > >
> > > Regards
> > > Maneesh Bhunwal
> > >
> >
> >
> >
>

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