Follower Catchup Init

FOLLOWER_CATCHUP_INIT - follower creates its Log Subscription and adds the Catchup endpoint to it (but not the Log endpoint). It tells the leader to start the Catchup process, then moves to FOLLOWER_CATCHUP_AWAIT

On Entry

On entry, the follower's Log contains all the entries up to the start of the current leadership term, and its Consensus Module has processed them. Its Clustered Service has started processing them and may be continuing in the background.

Enters from FOLLOWER_REPLAY if catchupJoinPosition is set on the Election object. This would have been set in onNewLeadershipTerm if the leader has already started accepting new Ingress messages and appending them to the Log in the current leadership term. This means the follower has to catch up to the leader by retrieving the missing Log entries, processing them, then transitioning to processing the live Log stream. This is Replay Merge, referred to as Catchup in Aeron Cluster. This Election state prepares the follower for receiving the missing entries (Catchup messages).

Description

The follower adds the Log Subscription if it doesn't already have one. This is an MDC Subscription with manual control, which means it won't listen for any Publications connecting to it automatically - it won't have any Subscription destinations. During Catchup, it will use two destinations - it will start by adding the Catchup endpoint, over which it will receive Log messages from the leader's Archive. When it has nearly caught up with the live Log position, it will also add the Log endpoint, over which it will receive live Log messages from the leader. The endpoints are both described in Cluster Member Endpoints and the general approach is described in Replay Merge.

After creating the Log Subscription, it adds the Catchup endpoint to it. This just makes the follower listen on the Catchup endpoint (this doesn't tell the leader), so the leader's Archive can connect to it later. It then resolves the Catchup endpoint - if it was configured with a port of 0, then this resolves the ephemeral port that was allocated to it.

It then sends a CatchupPosition message to the leader, telling it the resolved Catchup endpoint and Log position that it wants to catch up from.

This state is then complete, so it moves to FOLLOWER_CATCHUP_AWAIT.

On Exit

This follower has a Log Subscription with one destination added to it - the Catchup endpoint. It has sent a CatchupPosition message to the leader and has not yet received a response.

It moves to FOLLOWER_CATCHUP_AWAIT.