Scribd
Upload
56 views1 page

Redis Cluster Specification-25

The document discusses Redis cluster configuration and slave election and promotion. Key points: 1) Configuration epochs and current epochs are permanently stored on disk by nodes to prevent voting for slaves with outdated configurations. 2) Slave election is triggered when a master is in a FAIL state, and a slave can promote itself to master by winning an election. 3) For a slave to be elected, it must increment its current epoch and request votes from master nodes, waiting up to two node timeouts for responses.

Uploaded by

Kajaruban Surendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
56 views1 page

Redis Cluster Specification-25

The document discusses Redis cluster configuration and slave election and promotion. Key points: 1) Configuration epochs and current epochs are permanently stored on disk by nodes to prevent voting for slaves with outdated configurations. 2) Slave election is triggered when a master is in a FAIL state, and a slave can promote itself to master by winning an election. 3) For a slave to be elected, it must increment its current epoch and request votes from master nodes, waiting up to two node timeouts for responses.

Uploaded by

Kajaruban Surendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

configuration that needs to be updated (master nodes will not grant votes to slaves with

an old configuration).
Every time the configEpoch changes for some known node, it is permanently stored in
the [Link] file by all the nodes that receive this information. The same also
happens for the currentEpoch value. These two variables are guaranteed to be saved
and fsync-ed to disk when updated before a node continues its operations.

The configEpoch values generated using a simple algorithm during failovers are
guaranteed to be new, incremental, and unique.

Slave election and promotion


Slave election and promotion is handled by slave nodes, with the help of master nodes
that vote for the slave to promote. A slave election happens when a master is
in FAIL state from the point of view of at least one of its slaves that has the prerequisites
in order to become a master.
In order for a slave to promote itself to master, it needs to start an election and win it. All
the slaves for a given master can start an election if the master is in FAIL state,
however only one slave will win the election and promote itself to master.
A slave starts an election when the following conditions are met:

• The slave's master is in FAIL state.


• The master was serving a non-zero number of slots.
• The slave replication link was disconnected from the master for no longer than a given
amount of time, in order to ensure the promoted slave's data is reasonably fresh. This
time is user configurable.

In order to be elected, the first step for a slave is to increment its currentEpoch counter,
and request votes from master instances.
Votes are requested by the slave by broadcasting
a FAILOVER_AUTH_REQUEST packet to every master node of the cluster. Then it
waits for a maximum time of two times the NODE_TIMEOUT for replies to arrive (but
always for at least 2 seconds).
Once a master has voted for a given slave, replying positively with
a FAILOVER_AUTH_ACK, it can no longer vote for another slave of the same master
for a period of NODE_TIMEOUT * 2. In this period it will not be able to reply to other
authorization requests for the same master. This is not needed to guarantee safety, but

You might also like