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 <andreas@widdix.de> 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.
|