hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: HBase 1.x to 2.0 upgrade goals?
Date Wed, 27 Jan 2016 16:12:19 GMT
On Tue, Jan 26, 2016 at 2:58 PM, Matteo Bertozzi <theo.bertozzi@gmail.com>

> Hey,
> what are your goals/hopes for the 1.x to 2.0 migration?
> did we decided we can't have another cluster shutdown -> upgrade ->
> restart?
> or if we have replication working between 1.x and 2.x this is a valid
> option?
Has to be rolling upgradeable I'd say. Our long-time users will never
forgive us if we require another stop-the-world.

> one of the goal of the new Assignment is to be able to handle major
> migrations by knowing the state of the cluster in terms of "which version
> is each region server running" and with the ability to schedule region
> migration for fs format changes and similar "major" changes.
> (this requires an upgrade performed, Masters first and then RSs. this is
> what I always suggested to people but I never checked if this is what we
> are suggesting)
Refguide 'suggests' this
http://hbase.apache.org/book.html#hbase.rolling.upgrade We should harden it
to so master-first is required.

> also, the above may require (still looking into it) some new calls added to
> the 1.x line.
> is it acceptable to force people to move to the latest 1.x (e.g. 1.5.x)?
> or at least is it acceptable to force people to move to the latest 1.x.y
> (e.g. 1.1.232)?
I think this is acceptable.... If new migration APIs are being added,
should be a 1.5 rather than a 1.1.30000000000000

> did we decided that before going to 2.0 you have to be on a 1.x? meaning no
> direct upgrade from 0.98 to 2.0?
0.98 to 2.0 would be tough given nature of the changes in 2.0 and then the
need of new API to help migration. Would be sweet though if a 0.98->2.0
were possible... but migration is already hard enough to dev and test.. The
less migration path permutations supported, the better.

> and for how long should we keep upgrade/compatibility code in 2.x?
> can we force people to upgrade to 2.0 and then to the next 2.x?
I'd say its fine to purge migration code promptly after 2.0. Better to be
clear on what paths are migratable.


> thoughts?

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