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 <apa...@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
