hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Current status of 1.2.0RC0
Date Thu, 09 Jul 2015 18:55:04 GMT
> I'm concerned about a sever side hbase rolling upgrade where masters and
> rs's are different versions / settings.  E.g. Does a pv2 only master
> failover properly with a nonpv2 master in the presence of mixed version
> rs's.  Does the master failover test cover this situation?

This is a valid concern certainly. How we handled this in the 0.98 era,
which admittedly is looser by intent, is say that rolling upgrade are
supported IF the server fleet does not toggle on any new feature until all
server instances have been upgraded. Would that work here? I think it's a
reasonable story.


On Thu, Jul 9, 2015 at 6:47 AM, Jonathan Hsieh <jon@cloudera.com> wrote:

> Let's have some testing of this before we commit to this decision. I'd hate
> for us to be in a situation where reality doesn't jive with theory due to
> something self inflicted.  I also feel that removing well exercised code
> paths in minor versions seems risky. (No qualms for removing in major
> version)
>
> My main concern isn't hbase client to hbase server. I buy that.
>
> I'm concerned about a sever side hbase rolling upgrade where masters and
> rs's are different versions / settings.  E.g. Does a pv2 only master
> failover properly with a nonpv2 master in the presence of mixed version
> rs's.  Does the master failover test cover this situation?
>
> Jon
>
> On Monday, July 6, 2015, Enis Söztutar <enis@apache.org
> <javascript:_e(%7B%7D,'cvml','enis@apache.org');>> wrote:
>
> > >
> > >
> > > > Would not being able to opt out of this break rolling upgrade from
> 1.0
> > or
> > > 1.1?
> > >
> >
> > It should not (in theory). The client side does not need to know that the
> > operation is executed via proc v2. The HBaseAdmin class has the
> > compatibility layer to work with masters which know about proc v2 or not.
> > And if the client does not know about proc v2, it will still observe the
> > side affects (whether the tables regions are created in meta, etc) and
> work
> > as expected.
> >
> >
> > >
> > >
> > > > Enis
> > > >
> > > > On Sun, Jul 5, 2015 at 2:01 PM, Sean Busbey <busbey@cloudera.com>
> > wrote:
> > > >
> > > > > On Jul 5, 2015 1:36 PM, "Stack" <stack@duboce.net> wrote:
> > > > > >
> > > > > > On Sat, Jul 4, 2015 at 4:01 PM, Sean Busbey <busbey@cloudera.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Hi Folks!
> > > > > > >
> > > > > > > I believe I've now worked through the logistics to put
up the
> > first
> > > > RC
> > > > > for
> > > > > > > 1.2.0. At the moment I'm waiting on a Procedure V2 blocker[1],
> > > which
> > > > I
> > > > > hope
> > > > > >
> > > > > >
> > > > > > May I add HBASE-14012 to the above list Sean? (Almost done)
> > > > > >
> > > > >
> > > > > Fine by me. Please make sure it is blocker priority with a fix
> > version
> > > of
> > > > > 1.2.0.
> > > > >
> > > > > > 1.2.0 has Distributed Log Replay enabled by default. We good
with
> > > this?
> > > > > > I've not done much testing with it enabled. Have others?
> > > > > >
> > > > >
> > > > > I haven't yet. I figured during RC0 I'd try to hit it hard and then
> > > file
> > > > > tickets as needed.
> > > > >
> > > > > If we leave it on we'll need docs for how to do a rolling upgrade.
> > > > >
> > > > > > 1.2.0 also has flush-by-store enabled by default. This has been
> > > tested
> > > > a
> > > > > > bunch and looks pretty good to me.
> > > > > >
> > > > >
> > > > > Good to hear, this and can't-opt-out-procv2 are my other big
> > unknowns.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > // Jonathan Hsieh (shay)
> > > // HBase Tech Lead, Software Engineer, Cloudera
> > > // jon@cloudera.com // @jmhsieh
> > >
> >
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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