I had a problem getting dynamic reconfig to work on new / clean clusters, if I copied the zoo.cfg and zoo.cfg.dynamic.(number) file over from an older installation.
Here's what happens: [zk: localhost:2181(CONNECTED) 2] config server.1=srv5703h:2888:3888:participant;0.0.0.0:2181 server.2=srv5703k:2888:3888:participant;0.0.0.0:2181 server.3=srv5704y:2888:3888:participant;0.0.0.0:2181 version=1f001cc8d5 [zk: localhost:2181(CONNECTED) 3] reconfig -remove 3 Committed new configuration: server.1=srv5703h:2888:3888:participant;0.0.0.0:2181 server.2=srv5703k:2888:3888:participant;0.0.0.0:2181 server.3=srv5704y:2888:3888:participant;0.0.0.0:2181 version=1f001cc8d5 As you can see the config version doesnt change. If you check the filesystem, on each Zookeeper a ".next" file is created with the new config, but it seems like it's never committed. -rw-r-----. 1 prof prof 282 Jun 18 12:39 zoo.cfg -rw-r-----. 1 prof prof 159 Jun 18 15:25 zoo.cfg.dynamic.1f001cc8d5 -rw-r-----. 1 prof prof 123 Jun 18 15:26 zoo.cfg.dynamic.next On the Zookeepers where the reconfig command was NOT run, the logs show the following message: 2018-06-18 15:26:56,491 [myid:3] - INFO [ProcessThread(sid:3 cport:-1)::PrepRequestProcessor@476] - Incremental reconfig 2018-06-18 15:26:56,493 [myid:3] - ERROR [ProcessThread(sid:3 cport:-1)::QuorumPeer@1460] - setLastSeenQuorumVerifier called with stale config 4294967306. Current version: 133145872597 After growing a ton of grey hairs we figured out that a new cluster must start with an "unnumbered" dynamic config file, and copying over an existing config always fails. Can anyone explain why that is ? Thanks, Chris -- Sent from: http://zookeeper-user.578899.n2.nabble.com/
