Hi Andreas, Yes, the sync process is running async in one way, but sync in another! :-) The elected Zookeeper master will block (there are timeouts) a write until a quorum of the cluster has persisted the changed to disk. This means that, in a three node ensemble, you could have a single node lagging behind while the other two nodes aren't.
If the lagging-behind follower, lags behind `tickTime*syncLimit` (config parameters) milliseconds (usually something like 20 seconds), the master will drop its connection to it and ask the follower to rejoin/resync. Because of this, I usually run a `stat` command against my follower(s) and verify "mode: follower" and check that "xzid" is changing. That means I know my follower is between ~0 seconds and `tickTime*syncLimit` milliseconds behind the master. I hope this helps! Cheers, Jens On Wed, Apr 13, 2016 at 5:45 PM Andreas Wittig <[email protected]> wrote: > Hi, > > I'm new to the Zookeeper community. I've started using Zookeeper a few > months ago. > > My current goal is to build a rolling update process for three Zookeeper > nodes running on AWS. During the update the virtual machines get replaced > one by one. A new machine with Zookeeper is launched and added to > the ensemble. > > Unfortunately I'm ending up with inconsistent data in Zookeeper with my > current setup. > > Therefore I'd like to understand Zookeeper in more detail. > > Can somebody please point me to the answer of the following question: How > to verify if a new node (follower) of the ensemble has already synchronised > the current state from the leader? Is it enough to wait until SRVR returns > "Mode: follower"? Or is the sync process running async? > > --Andreas > -- Jens Rantil Backend Developer @ Tink Tink AB, Wallingatan 5, 111 60 Stockholm, Sweden For urgent matters you can reach me at +46-708-84 18 32.
