How is ‘write follows read’ guarantee maintained if a read request from a client goes to a follower server?
Say client’s view of clusterTime is 2, and a particular mongodb server’s clusterTime is 1. If a read request goes to the server with afterClusterTime 2, the server needs to update its clusterTime to make sure any subsequence write requests will happen at later time. To make sure that the clusterTime is updated, the server needs to make sure it ticks the clusterTime by doing a no-op write?
Its easy if the server where the read request is sent is a the primary. But what if the request goes to follower replica?
There are two scenarios here
- The primary might have already written something at clusterTime 2, and its just that the follower is not yet received the update, so it might just wait.
- The primary itself has not written anything in a while and its clusterTime is not updated to 2. In this case the follower needs to initiate a no-op write to update the cluster time through the primary…
Is this how its done in mongodb? Its tricky to figure out when to wait to catchup with all the updates from primary and when to trigger a no-op write. So followers can possibly just handle the read requests well in past and otherwise just redirect the read request to the primary?