hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@apache.org>
Subject Re: Planning for HBase 2.0
Date Tue, 08 Sep 2015 21:28:50 GMT
This is a nice list already Matteo!

+1, I think rolling upgrade should be supported -- said another way, we
need an *extremely* strong argument to justify NOT supporting rolling
upgrade. Your above approach sounds reasonable, and should allow for early
abort of the upgrade (i.e., before all machines are running new bits,
discontinue upgrade, restore old bits, everything keeps humming).

I have a meta question (maybe worth a separate thread), which is, what will
be the relationship between 2.0 and branch-1? Are we considering keeping
branch-1 alive (i.e., 1.3) even as 2.0 is released? Seems like you're
thinking about this in your later reply, but I haven't seen this topic
discussed explicitly.

On Mon, Sep 7, 2015 at 10:01 PM, Andrew Purtell <apurtell@apache.org> wrote:

> I filed HBASE-14379 as an umbrella to collect work for a "Replication V2"
> effort. The umbrella has a summary of principles and goals from the
> discussion at the recent dev meetup and a survey of open replication
> related issues.
>
>
> On Mon, Sep 7, 2015 at 9:42 PM, Matteo Bertozzi <theo.bertozzi@gmail.com>
> wrote:
>
> > on my list there are mainly major changes.
> > HBASE-13153 seems small enough that may also be considered for a
> branch-1.
> >
> > it will take at least 3 months to have a branch-2,
> > I don't want this thread to end up pointing out all minor jiras.
> > so, my rule is: if it is not a major architectural change and people +1
> it,
> > it is in.
> >
> > Matteo
> >
> >
> > On Mon, Sep 7, 2015 at 9:14 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> >
> > > Design for the following is being finalized:
> > > HBASE-13153 enable bulkload to support replication
> > >
> > > Do you think it should be included ?
> > >
> > > Cheers
> > >
> > > On Mon, Sep 7, 2015 at 8:42 PM, Matteo Bertozzi <mbertozzi@apache.org>
> > > wrote:
> > >
> > > > Hey folks,
> > > >
> > > > my list for 2.0 looks quite full, but I'm probably missing something.
> > > >
> > > > main point is probably that we want to be rolling upgradable.
> > > > a direct rolling upgrade may be not easy, so the option is to do it
> in
> > > two
> > > > phases.
> > > > more or less: "after all the machines are on the new version trigger
> an
> > > > update" (the new AM can help with it)
> > > >
> > > >  * HBASE-14350 New Assignment Manager (based on proc-v2)
> > > >  * Table Descriptor is not compatible with branch-1 due to HBASE-7767
> > > >  ** this may be reverted/removed/fixed with the new AM
> > > >  * HBASE-11425 Off heaping read path. write path?
> > > >  * HBASE-14090 redofs, fix 1M region. file moving around and so on
> > > >  * HBASE-14123 HBase Backups
> > > >  * Replication
> > > >  ** move znodes to replication table
> > > >  ** speedup replication by streaming data
> > > >  ** ability to run an endpoint as "user" and receive only "user"
> > events?
> > > >  * HBASE-13936 Dynamic configuration
> > > >  * HBASE-14070 HLC, was mentioned for branch-1. but maybe we can try
> to
> > > get
> > > > seqid merged?
> > > >
> > > > Other stuff like the C++ client from facebook, or improvement to the
> > > > Lawlor’s scanner work, spark integration, missing proc-v2 conversion
> > and
> > > > more can probably make it in a branch-1.
> > > >
> > > > cutting a branch-2 will probably happen when we have the new AM, but
> we
> > > > will see how things evolve.
> > > >
> > > > Anything else folks want to see called out?
> > > >
> > >
> >
>
>
>
> --
> 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