Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Peer that can't become leader


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
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB