Skip to content

Leader Log Replication

LEADER_LOG_REPLICATION - wait for enough followers to replicate missing Log entries up to the leader's Log position, so consensus can be achieved at that position

On Entry

Enters from CANDIDATE_BALLOT if it has been voted leader, or INIT if it's a single node cluster and is de facto leader.

Note that there is no special-casing code for a single node cluster. It still executes the same code to send messages to all the 'followers', but there are none. Similarly, the quorum threshold will be 1, so calculating the quorumPosition is essentially just using its own appendPosition - it doesn't need to wait for an AppendPosition message from any followers.

Log Publication

When transitioning to this state, it moves to the LEADER role, and creates the Log Publication. If the RecoveryPlan has a record of a previous Log, it sets the Log Publication's initial position to the appendPosition (which matches the Log Recording's stop position), otherwise it's set to zero. If the Log is MDC (its channel is UDP and has no endpoint parameter to connect out to), the other members' Log endpoints are added as destinations to the Log Publication.

Description

While in this state:

  • it calculates the quorumPosition - the append position that a majority of the members have reached
  • it publishes a NewLeadershipTerm message to the other members, on the leader heartbeat interval of 200 ms
  • it publishes a CommitPosition message (using quorumPosition as the logPosition) to the other members, either when it changes, or on the leader heartbeat interval

The leader waits until the quorumPosition catches up with its appendPosition. This will be the case once a majority of the members has a copy of the Log, up to the leader's append position. The followers will get to a stage in their Election where they send AppendPosition messages to the leader. If they are replicating the Log from the leader, the AppendPosition messages will reflect this. Once replicated, they will reach the start of the new leadership term, which will be the leader's append position.

Note that none of the members have processed the Log at this stage - up to now, they've just been ensuring that enough members have a Log Recording that matches the leader's.

Once quorumPosition catches up with the leader's appendPosition, it moves to LEADER_REPLAY

A single node cluster comes through this state because it needs the Log Publication setting up. It doesn't use it to publish to followers, but its Archive records from the Publication and the Clustered Service receives messages from it.

On Exit

  • A majority of the cluster members have a Log Recording that matches the leader's, and the Commit Position is at the end of the Recording, so it is safe to process up to that point. A minority of the followers may still be replicating the Log, or might not even be running. The leader and other followers move on regardless
  • The member moves to LEADER_REPLAY