Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Rolling upgrades


Copy link to this message
-
RE: Rolling upgrades
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB