I don't think there is a problem if you do it as you say, or even if you just change the config files of all servers at once and restart them, because a majority of the new config necessarily intersects with a majority of the old one, so a server who has the latest state will be elected leader.
Alex > -----Original Message----- > From: Jordan Zimmerman [mailto:[email protected]] > Sent: Thursday, March 08, 2012 3:31 PM > To: [email protected] > Subject: Rolling upgrades > > I've been reading the archives regarding rolling upgrades. Here's the > scenario, given a stable ensemble: > > ZK1 <-> ZK2 <-> ZK3 > > In the above, the zoo.cfg for each server looks like this (pseudo): > server.1=ZK1 > server.2=ZK2 > server.3=ZK3 > > I want to add a new server, ZK4. If I understand this correctly, I'd > bring up ZK4 with this config: > server.1=ZK1 > server.2=ZK2 > server.3=ZK3 > server.4=ZK4 > > At this point, though, the configs don't match in the ensemble. How do > the ZK instances handle this? > > Continuing... > > Once ZK4 is up, ZK1 would get the new config and get restarted. Once > ZK1 is up, ZK2 gets new config, etc. > > At each point of config change, the cluster is in a confused state > about the config. Is there code in ZK to handle this? > > -JZ
