Skip to content

Follower Log Replication

FOLLOWER_LOG_REPLICATION - use Archive Replication to copy one missing leadership term (in part or whole) from the leader's Archive, then move back to CANVASS

On Entry

Enters from FOLLOWER_BALLOT, CANDIDATE_BALLOT or CANVASS, when it receives a NewLeadershipTerm and finds that it is missing Log entries from before the start of the current leadership term. This can happen if the member died in one leadership term and the remaining members went on to hold an Election, starting a new leadership term.

See Replication and Catchup for an example.

Description

This state is used to replicate missing Log entries from the leader's Archive to the current member's Archive using Archive replication. It only replicates entries from one leadership term and can either replicate the whole term, or from part way through to the end. If more than one leadership term needs replicating, this state will be entered again, after going back to CANVASS.

It uses some values captured in onNewLeadershipTerm:

  • replicationLeadershipTermId - the leadership term to replicate
  • replicationStopPosition - the end of the leadership term to replicate (will always be set, otherwise the member would be using Catchup)
  • replicationTermBaseLogPosition - the start of the leadership term to replicate, if replicating from the start, otherwise set to NULL_VALUE. This is only used to update the Recording Log after replication has completed

It replicates from the current AppendPosition (the end of the Log Recording) to replicationStopPosition, then returns to CANVASS.

The diagram below is a more detailed look at Use Case 2 (steps 6 and 7) from the Aeron Archive part of the Detailed Overview.

Network Clustered Service consensus-module service Consensus Module control-response control-request Conductor Receiver Sender consensus1-0 consensus1-2 consensus0-1 consensus2-1 cnc.dat Clustered Service consensus-module service Consensus Module control-response control-request Conductor Receiver Sender consensus0-1 consensus0-2 log consensus1-0 consensus2-0 cnc.dat control-request-0 control-request-0 ControlSession ControlSession, ReplicationSession A RecordingSession Election (FOLLOWER_LOG_REPLICATION) Election (CANVASS) ControlSession RecordingReplication B A log recording term 2 term 1 term 0 0 C B D 0 log recording term 0 ReplaySession RecordingSession replication-1 replication-1 log ReplaySession RecordingSession log log-replay live control-request-0 ControlSession ControlSession control-request-0 ReplaySession RecordingSession log log-replay catchup ReplaySession RecordingSession replication-1 replication-1 control-request-0 ControlSession ControlSession, ReplicationSession control-request-0 RecordingSession RecordingSession log recording log recording log recording log recording snapshot1 snapshot2 archive.catalog snapshot1 snapshot2 archive.catalog ControlSession1, ReplicationSession1 ControlSession1, ReplicationSession1 RecordingSession1, 2, 3... RecordingSession1, 2, 3... ReplaySession1, 2, 3... ReplaySession1, 2, 3... Replayer Recorder Conductor Replayer Recorder Conductor Archive Archive FOLLOWER LEADER

Use the tabs above to step through the animation.



The Election's FOLLOWER_LOG_REPLICATION state asks the Consensus Module to start a new Log replication, to replicate up to the start of the nextLeadershipTermId (position B). It passes it the following values (the Archive already knows A):

  • the leader's Archive control endpoint, which a ReplayRequest can be sent to
  • the follower's Archive endpoint, which the leader's Archive will connect to, to send data (replicationChannel)
  • leaderRecordingId from the NewLeadershipTerm
  • replicationStopPosition from the NewLeadershipTerm, which is B above

The Consensus Module creates a RecordingReplication object, passing it those parameters. The RecordingReplication sends a ReplicateRequest2 to its Archive, asking it to replicate the log from the leader's Archive.

The Archive finds the stop position of its own recording (A) and creates a ReplicationSession, passing it all the parameters. The ReplicationSession coordinates the replication on the follower.

The ReplicationSession asks the Archive to extend the Log Recording (open for append). This creates a RecordingSession, which creates a Subscription on the replicationChannel (not shown, and the Image log buffer isn't created until the Publication connects). The RecordingSession will append any data sent to the Subscription to the end of the Log Recording.

Now that the Subscription is in place (not shown, but the follower's Receiver is listening on the replication endpoint), the ReplicationSession uses an ArchiveClient to connect to the leader's Archive (via its UDP Control Request channel), then sends it a ReplayRequest. The ReplayRequest contains the follower's replication channel so the leader's Archive can connect back to it.

The leader's Archive creates a ReplaySession to replay its Log Recording from position A to B. It connects to the follower's replication channel. The follower's RecordingSession receives the missing entries and appends them to the Log Recording. During replication, the follower's ReplicationSession sends RecordingSignalEvent messages to the Consensus Module (on the Control Response channel), which it forwards to the RecordingReplication. These are used to track replication progress. Also, the Election object sends AppendPosition messages to the leader periodically, telling it the current replication position.

Once replication is complete, everything is torn down and the follower moves to CANVASS. It will then repeat the same process to replicate leadership term 1.

On Exit

The member's Log Recording now contains entries that were previously missing, up to the start of the next leadership term. All the replication apparatus has completed and been torn down.

The member returns to CANVASS.