The only issue I see is that if the new server has the same id as the old one you're replacing, I think you should first remove the old one and then in a separate command add the new one. Intuitively this way you avoid having the newly joining server act as someone who knows the current state of the system (which it doesn't), a situation that may cause you to loose transactions.
Notice that there are two reconfig interfaces -- incremental and bulk (see manual <https://zookeeper.apache.org/doc/trunk/zookeeperReconfig.html>). On Sat, Nov 21, 2015 at 1:16 PM, Oboturov, Artem <[email protected]> wrote: > Hi > > I was looking at the ZK 3.5.x series new feature - dynamic configuration. > As an example, we could have an EC2 auto scaling group for 3 ZK nodes. When > one of them goes down, a new one would be spawned, but its IP could be > different. We could query EC2 to get all instances from group and generate > a config for ZK to take all currently running servers as part of ZK > cluster, and then run an update of cluster configs for all existing ones > using dynamic config feature. Would this strategy work? Are there any > alternatives? > > -- > Regards > Artem Oboturov >
