[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231859#comment-14231859
 ] 

Alexander Shraer commented on ZOOKEEPER-2076:
---------------------------------------------

See Figure 8 here: http://www.cs.technion.ac.il/~shralex/zkreconfig.pdf
I think what I did is just ran an ensemble locally, invoked a reconfig removing 
the leader and looked on the log, which includes the time. You can add logging 
if needed, but the current logging should probably be enough to understand when 
the old leader terminates and when the new one is established to measure total 
time. (I don't really remember if this is how I did it since it was more than 3 
years ago, but this is where I'd suggest to start).

Exactly, I believe its possible to do some things more efficiently, but I 
really haven't thought this through and not familiar with the current mechanism 
in detail. My current implementation of leader handoff is just an optimization 
that usually reduces the number of rounds required in FLE to 1. 

I also suspect that one can even skip FLE completely and have them try to 
connect to the new leader and only if that fails go back to FLE. Not sure this 
is worth doing - it depends where the time is spent currently.


> Improve Leader Change Mechanism
> -------------------------------
>
>                 Key: ZOOKEEPER-2076
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2076
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.5.0
>            Reporter: Alexander Shraer
>
> When a leader is removed during a reconfiguration, ZOOKEEPER-107 uses a 
> mechanism where the old leader nominates the new one. Although it reduces the 
> time for a new leader to be elected, it still takes too long. This JIRA is 
> for two things:
> 1. Improve the mechanism, e.g., avoid loading snapshots, etc. during the 
> handoff.
> 2. Make it a first-class citizen & export it as a client API. We get 
> questions about this once in a while - how do I cause a different leader to 
> be elected ? Currently the response is either kill or reconfigure the current 
> leader.
> Any one interested to work on this ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to