MongoDB Documentation, Release 3.0.4 Check the Replication Lag Replication lag is a delay between an operation on the primary and the application of that operation from the oplog to the secondary . Replication lag can be a significant issue and can seriously affect MongoDB replica set deployments. Excessive replication lag makes “lagged” members ineligible to quickly become primary and increases the possibility that distributed read operations will be inconsistent. To check the current length of replication lag: • In a mongo shell connected to the primary, call the rs.printSlaveReplicationInfo() method. Returns the syncedTo value for each member, which shows the time when the last oplog entry was written to the secondary, as shown in the following example: source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary A delayed member (page 570) may show as 0 seconds behind the primary when the inactivity period on the primary is greater than the slaveDelay value. Note: The rs.status() method is a wrapper around the replSetGetStatus database command. • Monitor the rate of replication by watching the oplog time in the “replica” graph in the MongoDB Cloud Man- ager 21 and in Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced$^{22}$. For more information see the MongoDB Cloud Manager documentation 23 and Ops Manager documentation$^{24}$. Possible causes of replication lag include: • Network Latency Check the network routes between the members of your set to ensure that there is no packet loss or network routing issue. Use tools including ping to test latency between set members and traceroute to expose the routing of packets network endpoints. • Disk Throughput If the file system and disk device on the secondary is unable to flush data to disk as quickly as the primary, then the secondary will have difficulty keeping state. Disk-related issues are incredibly prevalent on multi-tenant systems, including virtualized instances, and can be transient if the system accesses disk devices over an IP network (as is the case with Amazon’s EBS system.) Use system-level tools to assess disk status, including iostat or vmstat . • Concurrency In some cases, long-running operations on the primary can block replication on secondaries. For best results, configure write concern (page 78) to require confirmation of replication to secondaries, as described in replica set write concern (page 80). This prevents write operations from returning if replication cannot keep up with the write load. $^{21}$https://cloud.mongodb.com/?jmp=docs $^{22}$https://www.mongodb.com/products/mongodb-enterprise-advanced?jmp=docs $^{23}$https://docs.cloud.mongodb.com/ $^{24}$https://docs.opsmanager.mongodb.com/current 9.3. Replica Set Tutorials 647