zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lvfangmin <...@git.apache.org>
Subject [GitHub] zookeeper issue #703: [ZOOKEEPER-1818] Correctly handle potential inconsiste...
Date Sun, 25 Nov 2018 08:02:47 GMT
Github user lvfangmin commented on the issue:

    @anmolnar following are my understanding about the acceptedEpoch, currentEpoch and electionEpoch:
    * acceptedEpoch : the previous epoch we accepted so far, usually is the epoch is the highest
zxid on that server.
    * currentEpoch  : the current epoch after syncing with the new leader, it's based on the
maximum acceptedEpoch in the quorum, and usually it's the max(acceptedEpoch) + 1. The currentEpoch
is used as the peerEpoch in the leader election, as we know (sid, zxid, peerEpoch) are the
set used to decide a leader.
    * electionEpoch : not part of the factors to decide leader, but it's used as a logical
clock to avoid considering a vote delayed from a while ago.
    Basically, we know there is a corner case where the learner may not update it's zxid,
peerEpoch, and electionEpoch after leader election (check the new comment I added Leader.updateElectionVote),
peerEpoch is fixed with a hack solution, but we cannot easily update the zxid and electionEpoch,
so we try to ignore it. But IGNOREVALUE introduced will have compatible issue when rolling
upgrade ensemble, that's why we introduced version in notification, and only compare id or
peerEpoch based on version.


View raw message