zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Horowitz <bhoro...@gmail.com>
Subject Re: Peer that can't become leader
Date Fri, 06 Sep 2013 04:59:54 GMT
Thanks, Camille. I just asked on user@zookeeper in addition to your
blog because I thought someone here would know, and that you might be

Flavio, just to outline the scenario, there are 3 regions involved
(say 1, 2, and 3), each with A and B datacenters. A and B datacenters
are connected by a fat low-latency pipe, but regions are on different
continents. Each region has its own quorum, with N peers in datacenter
A, N peers in datacenter B, and 1 peer P in the nearest datacenter in
a different region. The main requirement is that the services provided
by the system should remain available if any one datacenter gets lost
or partitioned. P is the peer that shouldn't become the leader, if
possible, so that the more remote P isn't on the critical path for
update ops. P is expected to lag in voting, but that's OK, as normally
at least N+1 from the remaining 2N nodes in the same region will vote
with low latency.

Anyhow, thanks for the responses!


On Thu, Sep 5, 2013 at 9:52 AM, Camille Fournier <camille@apache.org> wrote:
> Hi Ben,
> Sorry I haven't replied to your post comment. This was "manual" in that we
> made sure things like restart scripts would restart this instance last, and
> we would monitor that server and restart it if it ever became the elected
> leader. It's not ideal but it works, and that's the only way to do what I
> suggested because observers are not voting members and thus can't help with
> the datacenter failure issue.
> Best,
> Camille
> On Thu, Sep 5, 2013 at 3:00 AM, Flavio Junqueira <fpjunqueira@yahoo.com>wrote:
>> Are you asking about observers? Observers don't vote and are not elected.
>> -Flavio
>> -----Original Message-----
>> From: "Ben Horowitz" <bhorowit@gmail.com>
>> Sent: 05/09/2013 06:57
>> To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
>> Subject: Peer that can't become leader
>> Hi all,
>> Camille Fournier in her blog post on a global service discovery
>> infrastructure using ZK [1] describes a setup in which, by design, a
>> distinguished peer P never becomes leader.
>> Is there any way of accomplishing this setup with ZK config files? Or
>> would one have to watch the ensemble and restart P if ever P becomes
>> leader?
>> [1]
>> http://whilefalse.blogspot.com/2012/12/building-global-highly-available.html#comment-form
>> Thanks,
>> Ben

View raw message