If secondaries are FALLING behind they are experiencing REPLICATION lag, which is a delay in the application of oplog from primary to secondary. Replication lag can be a significant issue and can seriously affect MongoDB replica set deployments. Excessive replication lag makes a member ineligible to quickly become primary and increases the possibility of distributed read operations to be inconsistent.

We can check the replication lag by calling the rs.printSlaveReplicationInfo() method or by running the rs.status() command.

Possible causes of replication lag include:

1. Issues related to network between primary and secondary server. Sometimes the network becomes a bottleneck. We should ensure there is no packet loss or any other network related issues.
2. Disk issues on the secondary server. Sometimes there are different hardware on primary and secondary. If the primary is using SSD and secondary HDD, then disk flushes will be slow and secondary will lag behind. There might be other disk issues which can be checked by vmstat and iostat.
3. Sometimes there can be an issue due to concurrency issues as long-running operations on the primary can block replication on secondary. We should configure write CONCERN to require acknowledgement of replication to secondary. This prevents write operations from returning if replication cannot keep up with the write load.