> 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 <[email protected]> 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected]> > > wrote: > > > > > > > > > On Jul 5, 2015 1:36 PM, "Stack" <[email protected]> wrote: > > > > > > > > > > > > On Sat, Jul 4, 2015 at 4:01 PM, Sean Busbey <[email protected] > > > > > > 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 > > > // [email protected] // @jmhsieh > > > > > > > > -- > // Jonathan Hsieh (shay) > // HBase Tech Lead, Software Engineer, Cloudera > // [email protected] // @jmhsieh > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
