You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Diogo (JIRA)" <ji...@apache.org> on 2010/09/14 09:40:33 UTC
[jira] Created: (ZOOKEEPER-869) Support for election of leader with
arbitrary zxid
Support for election of leader with arbitrary zxid
--------------------------------------------------
Key: ZOOKEEPER-869
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
Project: Zookeeper
Issue Type: New Feature
Reporter: Diogo
Priority: Minor
Fix For: 4.0.0
Currently, the leader election algorithm implemented guarantees that the leader has the maximum zxid of the ensemble. The state synchronization after the election was built based on this assumption. However, other leader elections algorithms might elect leaders with arbitrary zxid.
To support other leader election algorithms, the state synchronization should allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-869) Support for election of leader
with arbitrary zxid
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910643#action_12910643 ]
Benjamin Reed commented on ZOOKEEPER-869:
-----------------------------------------
this is a good observation diogo, but i think you may be characterizing it improperly. the problem is that when we do a leadership we increment the epoch and propose a new leader, so all other processes will be much lower than the leader. when a follower connects we figure out how far behind the follower is by comparing the lastProposed zxids and taking the difference. we should really be using the recent history to do the comparison.
as a side note, if we were to chose not to take the maximum zxid during recovery, we need to make sure that we still cover all committed messages.
> Support for election of leader with arbitrary zxid
> --------------------------------------------------
>
> Key: ZOOKEEPER-869
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Diogo
> Priority: Minor
>
> Currently, the leader election algorithm implemented guarantees that the leader has the maximum zxid of the ensemble. The state synchronization after the election was built based on this assumption. However, other leader elections algorithms might elect leaders with arbitrary zxid.
> To support other leader election algorithms, the state synchronization should allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-869) Support for election of leader
with arbitrary zxid
Posted by "Diogo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912980#action_12912980 ]
Diogo commented on ZOOKEEPER-869:
---------------------------------
Thanks for the comment. I opened a new issue based on this: ZOOKEEPER-876.
> Support for election of leader with arbitrary zxid
> --------------------------------------------------
>
> Key: ZOOKEEPER-869
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Diogo
> Priority: Minor
>
> Currently, the leader election algorithm implemented guarantees that the leader has the maximum zxid of the ensemble. The state synchronization after the election was built based on this assumption. However, other leader elections algorithms might elect leaders with arbitrary zxid.
> To support other leader election algorithms, the state synchronization should allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-869) Support for election of leader with
arbitrary zxid
Posted by "Diogo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Diogo updated ZOOKEEPER-869:
----------------------------
Fix Version/s: (was: 4.0.0)
> Support for election of leader with arbitrary zxid
> --------------------------------------------------
>
> Key: ZOOKEEPER-869
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Diogo
> Priority: Minor
>
> Currently, the leader election algorithm implemented guarantees that the leader has the maximum zxid of the ensemble. The state synchronization after the election was built based on this assumption. However, other leader elections algorithms might elect leaders with arbitrary zxid.
> To support other leader election algorithms, the state synchronization should allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-869) Support for election of leader
with arbitrary zxid
Posted by "Diogo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910531#action_12910531 ]
Diogo commented on ZOOKEEPER-869:
---------------------------------
While trying to implement this, I found an interesting issue. Say we have an ensemble with 3 nodes. Say we start all nodes together and all have the state synchronized, meaning, all replicas return the same value with ZKDatabase().getLastLoggedZxid(). It seems that the leader will send a snapshot to all followers, although that is not necessary. They need no state transfer.
The leader (quorum/Leader.java:283) reads its lastLoggedZxid() and adds a new epoch on it and stores it as lastProposed. In LearnerHandler.java:308 the thread will decide if the replica needs an empty DIFF otherwise a SNAP. (I am assuming the state of the system described above). But startForwarding will return lastProposed, which is necessarily larger than any other zxid. Then SNAP will be selected and sent.
Here there is the part of an output, where 2 replicas have the same state stored and one is behind.
2010-09-17 12:11:27,296 [myid:3] - INFO [QuorumPeer:/0:0:0:0:0:0:0:0:2183:FileSnap@82] - Reading snapshot /tmp/zoo3/version-2/snapshot.700000000
2010-09-17 12:11:27,298 [myid:3] - INFO [QuorumPeer:/0:0:0:0:0:0:0:0:2183:FileSnap@82] - Reading snapshot /tmp/zoo3/version-2/snapshot.700000000
2010-09-17 12:11:27,301 [myid:3] - INFO [QuorumPeer:/0:0:0:0:0:0:0:0:2183:FileTxnSnapLog@208] - Snapshotting: 700000000
2010-09-17 12:11:27,303 [myid:3] - INFO [QuorumPeer:/0:0:0:0:0:0:0:0:2183:Leader@285] - lastLoggedZxid = 700000000 lastProposed = 800000000 <---------- added line just after leader sets its lastProposed
2010-09-17 12:11:27,309 [myid:3] - INFO [LearnerHandler-/127.0.0.1:48318:LearnerHandler@247] - Follower sid: 1 : info : org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer@12d3205
2010-09-17 12:11:27,310 [myid:3] - WARN [LearnerHandler-/127.0.0.1:48318:LearnerHandler@326] - Sending snapshot last zxid of peer is 0x700000000 zxid of leader is 0x800000000 <------ snapshot being sent!
2010-09-17 12:11:27,312 [myid:3] - WARN [LearnerHandler-/127.0.0.1:48318:Leader@474] - Commiting zxid 0x800000000 from /127.0.0.1:2890 not first!
2010-09-17 12:11:27,313 [myid:3] - WARN [LearnerHandler-/127.0.0.1:48318:Leader@476] - First is 0
2010-09-17 12:11:27,313 [myid:3] - INFO [LearnerHandler-/127.0.0.1:48318:Leader@500] - Have quorum of supporters; starting up and setting last processed zxid: 34359738368
2010-09-17 12:11:28,290 [myid:3] - INFO [LearnerHandler-/127.0.0.1:48319:LearnerHandler@247] - Follower sid: 2 : info : org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer@1319c
2010-09-17 12:11:28,291 [myid:3] - WARN [LearnerHandler-/127.0.0.1:48319:LearnerHandler@326] - Sending snapshot last zxid of peer is 0x600000000 zxid of leader is 0x800000000 <---- this follower needs the snapshot.
Am I understanding something wrong?
> Support for election of leader with arbitrary zxid
> --------------------------------------------------
>
> Key: ZOOKEEPER-869
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Diogo
> Priority: Minor
>
> Currently, the leader election algorithm implemented guarantees that the leader has the maximum zxid of the ensemble. The state synchronization after the election was built based on this assumption. However, other leader elections algorithms might elect leaders with arbitrary zxid.
> To support other leader election algorithms, the state synchronization should allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.