A follower can fail due to a number of reasons such as disk failure, network partition, power outage etc or it can even be brought down intentionally for routine maintenance. When the follower comes back online it must catch up to the current data state the leader holds. However, in order to do so, the follower must know the last transaction it successfully completed before going offline. The follower maintains a log of the changes received from the leader on its local disk and can easily lookup the last successful transaction it processed and request the leader for all the transactions that occurred after. In this way the follower catches up to the leader.

Some of the issues that can come up in this scheme are:

On a very busy system if the follower comes back online after a significantly long time such that it is perpetually behind the leader and can never catch up due to sheer volume of changes happening in the system.

The leader may roll-over its replication log after a few days and not have the changes requested by the follower. For instance, if the leader keeps the replication log history for the last 15 days and the follower comes back online after twenty days then the follower may not be able to get changes for the earliest five days.