Current epoch & config epoch

[Liuyi Wang]

Hi, all,
in redis cluster (sharding with multi masters), I don't have a good understanding about current epoch and config epoch.

I have some basic understanding that
config epoch, is kind of a "version" of the topology of masters.
Or I want to say, it's a "version" of a distribution of Hash slots.

 While current epoch is like a time stamp of "event".
Before a slave asks to be promoted, it will increment its current epoch.
And after the failover gets votes from majority of masters, the salve will somehow get a unique config epoch (larger than others, as a new master).

1. Is there any other event which increments current epoch?

Here are something confusing me in the doc

"Every time a packet is received from another node, if the epoch of the sender (part of the cluster bus messages header) is greater than the local node epoch, the currentEpoch is updated to the sender epoch.

Because of these semantics, eventually all the nodes will agree to the greatest configEpoch in the cluster."
Why configEpoch at the end?


"In order to enforce this, a conflict resolution algorithm is used in the event that two nodes end up with the same configEpoch.

• IF a master node detects another master node is advertising itself with the same configEpoch.
• AND IF the node has a lexicographically smaller Node ID compared to the other node claiming the same configEpoch.
• THEN it increments its currentEpoch by 1, and uses it as the new configEpoch."
  
  Why increment currentEpoch?
  This gives a me feeling that, new unique configEpoch generated after failover will also be assigned to currentEpoch? This assumption also explains the first confusion.
  But this is a guess, never stated in doc.
  If not, I can't really understand the logic here.

Appreciate your answer.
Thank you very much.
L.W.

[Weiyue Li]

Consider the configEpoch is the data that needs to be propagated across the cluster.

A higher version of configEpoch means a more up to date slot map. Sender node and receiver node will settle to the highest configEpoch by Heartbeat and UPDATE messages.

The above explains that:

"eventually all the nodes will agree to the greatest configEpoch in the cluster."

On the other hand, currentEpoch is the version of the current node. This value is mainly used for leader election. 

It prevents that a master cannot vote a slave more than once in the same round and prevent a slave does not take votes from previous around.

Also, in the case of conflict resolution, when master nodes contains the same configEpoch, the node with lower node ID will increase its currentEpoch to identity itself as the dictator, and its configEpoch will eventually be propagated across the cluster since nodes always take data from nodes with higher currentEpoch.