[ZOOKEEPER-3608] add a documentation about currentEpoch and acceptEpoch

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: documentation, leaderElection, server
• Assignee: Ling Mao
• Reporter: Ling Mao
• Created: 07/Nov/19 10:33
• Updated: 17/Nov/19 10:10

Description

Users may confuse about these two variables:acceptedEpoch and currentEpoch introduced by this ticket.

The implementation up to version 3.3.3 has not included epoch variables acceptedEpoch and currentEpoch. This omission has generated problems in a production version and was noticed by many ZooKeeper clients.

− acceptedEpoch: the epoch number of the last NEWEPOCH message accepted;
− currentEpoch: the epoch number of the last NEWLEADER message accepted;

The origin of this problem is at the beginning of Recovery Phase, when the leader increments its epoch (contained in lastZxid) even before acquiring a quorum of successfully connected followers (such leader is called false leader). Since a follower goes back to FLE if its epoch is larger than the leader’s epoch, when a false leader drops leadership and becomes a follower of a leader from a previous epoch, it finds a smaller epoch and goes back to FLE. This behavior can loop, switching from Recovery Phase to FLE repeatedly.
Consequently, using lastZxid to store the epoch number, there is no distinction between a tried epoch and a joined epoch in the implementation. Those are the respective purposes for acceptedEpoch and currentEpoch, hence the omission of them render such problems.

More details can be found in this report paper: ZooKeeper’s atomic broadcast protocol: Theory and practice. Andr ́e Medeiros March 20, 2012

Issue Links

• is related to: ZOOKEEPER-335 zookeeper servers should commit the new leader txn to their logs.