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 >> leader election length


Copy link to this message
-
Re: leader election length
Existing sessions will not expire from the server side during election.
Your client code may choose to close them on its end if you sit in a
DISCONNECTED state for too long, but nothing should be expiring the
sessions while quorum is not available.

C

On Mon, Dec 12, 2011 at 12:06 PM, Botond Hejj <[EMAIL PROTECTED]
> wrote:

> Hi ZooKeeper users,
>
> I am playing currently with zookeeper and testing what happens if the
> leader of an ensemble goes down.
> I know that during the leader election zookeeper server won't reply to
> any requests and if leader election takes a long time than existing
> sessions might expire.
> What I see in my tests that each server reads the last snapshot file
> to get last zxid for leader election and when the leader is elected
> than the leader reads the snapshot again before it syncs the
> followers.
>
> This means that the more data we store in zookeeper the longer it
> takes to elect a new leader. This is also means as load of the
> ensemble increases clients need bigger session timeout to "survive"
> the loss of the leader.
>
> Is it possible to do anything about this and have a fast leader
> election even if the snapshot is big?
>
> Regards,
> Botond Hejj
>
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