zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Rantil <jens.ran...@tink.se>
Subject Re: Problems with rolling update
Date Sat, 16 Apr 2016 09:45:01 GMT
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!


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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message