Todd, you can try using flexible quorums to implementing what your
requesting. You can simulate the behavior I described of observers by
setting the weight of the server to zero. Please check the
Check under "Cluster Options" options like group and weight.
On Jul 24, 2009, at 5:03 PM, Todd Greenwood wrote:
In the future, once the Observers feature is implemented, then we
be able to deploy zk servers to both the DC and to the pods...with all
the goodness that Flavio mentions below.
From: Flavio Junqueira [mailto:f...@yahoo-inc.com]
Sent: Friday, July 24, 2009 4:50 PM
Subject: Re: Zookeeper WAN Configuration
Just a few quick observations:
On Jul 24, 2009, at 4:40 PM, Ted Dunning wrote:
On Fri, Jul 24, 2009 at 4:23 PM, Todd Greenwood
Could you explain the idea behind the Observers feature, what this
concept is supposed to address, and how it applies to the WAN
configuration problem in particular?
Not really. I am just echoing comments on observers from them that
Without observers, increasing the number of servers in an ensemble
enables higher read throughput, but causes write throughput to drop
because the number of votes to order each write operation increases.
Essentially, observers are zookeeper servers that don't vote when
ordering updates to the zookeeper state. Adding observers enables
higher read throughput affecting minimally write throughput (leader
still has to send commits to everyone, at least in the version we have
been working on).
The ideas for federating ZK or allowing observers would likely do
want. I can imagine that an observer would only care that it can
local peers and one of the observers would be elected to get updates
thus would care about the central service).
This certainly sounds like exactly what I want...Was this
3.2 in full, or only partially?
I don't think it is even in trunk yet. Look on Jira or at the
of this mailing list.
It is not on trunk yet.