zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Franke <jornfra...@gmail.com>
Subject Re: One node crashing in 3.4.11 triggered a full ensemble restart
Date Thu, 03 Oct 2019 13:14:31 GMT
I can confirm that a rolling update from Zk 3.4 to ZK 3.5 is possible if and only if a ZK ensemble
is used. standalone updates may introduce difficulties. 
Of course I cannot tell for all possible setups, but for a ZK ensemble with multiple Solr
instances it is possible.

> Am 03.10.2019 um 14:55 schrieb Shawn Heisey <apache@elyograg.org>:
> On 10/3/2019 2:45 AM, Norbert Kalmar wrote:
>> As for running a mixed version of 3.5 and 3.4 quorum - I'm afraid it will
>> not work. From 3.5 we have a check on PROTOCOL_VERSION. 3.4 did not have
>> this protocol version, so when the nodes try to communicate it will throw
>> an exception. Plus, it is not a goal to keep quorum protocol backward
>> compatible, so chances are even without the check it would not work.
> This document suggests that a mixed environment of 3.4 and 3.5 will work:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> But you seem to be saying that it won't.
> As a committer on the Lucene/Solr project (which uses ZK) I am wondering what we can
tell our users about upgrading ZK.  I was under the impression from the wiki page I linked
that they could do a rolling upgrade with zero downtime, where they do one ZK server at a
time.  Are you saying that this is not possible?
> The Upgrade FAQ that you linked doesn't say anything about 3.4 and 3.5 not working together.
 The only big gotcha I see there is ZOOKEEPER-3056, which has a workaround.
> (I think of 4lw whitelisting as just a config problem with a new default, not a true
upgrade issue)
> Thanks,
> Shawn

View raw message