hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: DISCUSSION: Minimum hbase1 version from which you can upgrade to hbase2 (1.2.x?)
Date Sat, 11 Nov 2017 20:46:28 GMT
On Thu, Nov 9, 2017 at 9:06 PM, Yu Li <carp84@gmail.com> wrote:

> Sorry for the late response boss. We're still on 1.1 and have been keeping
> a close watch on 2.0 progress (silently though, sorry about this, occupied
> by singles day). If 1.2 could rolling upgrade to 2.0, anything special that
> prevents 1.1 to (could you please refer me to some JIRA)? Thanks.
>
>
Don't know. Will shout if I find anything. Will try it soon (next week or
so).


> Rolling upgrade is a must-have for us when choosing the next version, and
> since we have already backported the offheap work, 2.0 would be the first
> choice for us than 1.4 (to avoid the pain of another round patch porting)
> (smile)
>
> Good to know.

Going to an intermediate version would be a PITA for you I'm sure.

St.Ack



> Best Regards,
> Yu
>
> On 9 November 2017 at 14:08, Stack <stack@duboce.net> wrote:
>
> > FYI, I'm resolving HBASE-13631 "Migration from 0.94 to 2.0.0" because of
> > the discussion here on this thread.
> >
> > Sounds like 1.2 is minimum but lets try and see if we can go from 0.98.
> >
> > Thanks,
> > S
> >
> > On Sat, Nov 4, 2017 at 9:41 PM, Stack <stack@duboce.net> wrote:
> >
> > > On Sat, Nov 4, 2017 at 6:19 PM, Guanghao Zhang <zghaobac@gmail.com>
> > wrote:
> > >
> > >> Our internal branch is based on 0.98. And we plan rolling to 2.0. So I
> > >> will
> > >> take a try for rolling from 0.98 to 2.0. But we take a lot backport to
> > our
> > >> internal branch, like async client, netty rpc client, serial
> > replication,
> > >> throttling, some replication improvements and so on. So our rolling
> > >> experience may not apply to community totally. I will post our rolling
> > >> experience (which can apply to community 0.98 branch) after we rolling
> > to
> > >> 2.0 :-).
> > >>
> > >>
> > > Let me try going from 0.98 then and see what is broke. Would be good if
> > > you fellows could do one step rather than two.
> > > S
> > >
> > >
> > >
> > >
> > >> 2017-11-05 2:41 GMT+08:00 Stack <stack@duboce.net>:
> > >>
> > >> > On Fri, Nov 3, 2017 at 9:01 PM, Guanghao Zhang <zghaobac@gmail.com>
> > >> wrote:
> > >> >
> > >> > > Can we rolling from 0.98 and 1.1 to 1.2? If this rolling is ok,
> user
> > >> can
> > >> > > rolling to 2.0 by two steps, 0.98 to 1.2, then 1.2 to 2.0.
> > >> > >
> > >> > >
> > >> > Yes. They could do that. Would be a pain. Might be able to go from
> > 0.98
> > >> to
> > >> > 2.0 though... I've not tried it.
> > >> > St.Ack
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > > 2017-11-04 11:25 GMT+08:00 Nick Dimiduk <ndimiduk@gmail.com>:
> > >> > >
> > >> > > > 1.2 is good, but are we aware of anything that precludes
1.1?
> > 0.98?
> > >> On
> > >> > > disk
> > >> > > > compatibility (HFile, WAL, AMv2) should be the limiting
factor
> > here,
> > >> > > right?
> > >> > > > Wire protocols have been compatible all the while...
> > >> > > >
> > >> > > > On Fri, Nov 3, 2017 at 5:56 PM Zach York <
> > >> zyork.contribution@gmail.com
> > >> > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > +1 for having the minimum (supported) hbase1 version
be 1.2.x.
> > >> > > > >
> > >> > > > > On Fri, Nov 3, 2017 at 5:30 PM, Stack <stack@duboce.net>
> wrote:
> > >> > > > >
> > >> > > > > > Over in the adjacent "[DISCUSS] hbase-2.0.0 compatibility
> > >> > > expectations"
> > >> > > > > > thread, we chatted some on what would be the minimum
> hbase-1.x
> > >> > > version
> > >> > > > > from
> > >> > > > > > which you can upgrade to hbase-2.
> > >> > > > > >
> > >> > > > > > The last statement made on this topic by Sean
was that only
> > >> > upgrades
> > >> > > > from
> > >> > > > > > 1.2.x, our current stable offering, or later should
be
> > >> supported.
> > >> > > > > >
> > >> > > > > > There was no dissent.
> > >> > > > > >
> > >> > > > > > We all good w/ this? Speak up if you disagree
else 1.2.x
> > becomes
> > >> > the
> > >> > > > > > 'official' minimum.
> > >> > > > > >
> > >> > > > > > NOTES:
> > >> > > > > >
> > >> > > > > > + We need to agree on a minimum so we know what
migrations
> to
> > >> test.
> > >> > > > > > + It might be possible to upgrade from versions
before 1.2.x
> > >> but we
> > >> > > (or
> > >> > > > > at
> > >> > > > > > least I -- smile) won't have tried it or run verifications
> to
> > >> > ensure
> > >> > > > all
> > >> > > > > > made it over (let us know if you successfully
migrate from a
> > >> > baseline
> > >> > > > > that
> > >> > > > > > precedes 1.2).
> > >> > > > > > + Hopefully we can avoid requiring Users move
to the latest
> on
> > >> the
> > >> > > 1.2
> > >> > > > > > branch. This shouldn't be necessary doing a stop/start
> > upgrade.
> > >> It
> > >> > > > might
> > >> > > > > be
> > >> > > > > > needed doing a rolling upgrade. Lets see.
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > > St.Ack
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

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