AlsoŠ I thought that ZK ensembles need to be odd in number. How would ZK handle a temporary state where there is an even number?
-JZ On 3/8/12 3:39 PM, "Alexander Shraer" <shra...@yahoo-inc.com> wrote: >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:jzimmer...@netflix.com] >> Sent: Thursday, March 08, 2012 3:31 PM >> To: user@zookeeper.apache.org >> 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 > >
