Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # user >> RE: Peer that can't become leader


+
Flavio Junqueira 2013-09-05, 07:00
+
Camille Fournier 2013-09-05, 16:52
Copy link to this message
-
Re: Peer that can't become leader
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
busy.

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!

Ben

On Thu, Sep 5, 2013 at 9:52 AM, Camille Fournier <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>wrote:
>
>> Are you asking about observers? Observers don't vote and are not elected.
>>
>> -Flavio
>>
>> -----Original Message-----
>> From: "Ben Horowitz" <[EMAIL PROTECTED]>
>> Sent: 05/09/2013 06:57
>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>> 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
>>
+
Ben Horowitz 2013-09-05, 04:57