MongoDB Documentation, Release 3.0.4 Replication and Monitoring Beyond the basic monitoring requirements for any MongoDB instance, for replica sets, administrators must monitor replication lag . “Replication lag” refers to the amount of time that it takes to copy (i.e. replicate) a write operation on the primary to a secondary . Some small delay period may be acceptable, but two significant problems emerge as replication lag grows: Note: The size of the oplog is only configurable during the first run using the --oplogSize argument to the mongod command, or preferably, the oplogSizeMB setting in the MongoDB configuration file. If you do not specify this on the command line before running with the --replSet option, mongod will create a default sized oplog. By default, the oplog is 5 percent of total available disk space on 64-bit systems. For more information about changing the oplog size, see the Change the Size of the Oplog (page 628) For causes of replication lag, see Replication Lag (page 647). Replication issues are most often the result of network connectivity issues between members, or the result of a primary that does not have the resources to support application and replication traffic. To check the status of a replica, use the replSetGetStatus or the following helper in the shell: rs.status() The replSetGetStatus reference provides a more in-depth overview view of this output. In general, watch the value of optimeDate , and pay particular attention to the time difference between the primary and the secondary members. In most cases, the components of sharded clusters benefit from the same monitoring and analysis as all other MongoDB instances. In addition, clusters require further monitoring to ensure that data is effectively distributed among nodes and that sharding operations are functioning appropriately. See the Sharding Concepts (page 667) documentation for more information. Config Servers The config database maintains a map identifying which documents are on which shards. The cluster updates this map as chunks move between shards. When a configuration server becomes inaccessible, certain sharding operations become unavailable, such as moving chunks and starting mongos instances. However, clusters remain accessible from already-running mongos instances. Because inaccessible configuration servers can seriously impact the availability of a sharded cluster, you should mon- itor your configuration servers to ensure that the cluster remains well balanced and that mongos instances can restart. MongoDB Cloud Manager 41 and Ops Manager 42 monitor config servers and can create notifications if a config server Sharding and Monitoring See also: $^{41}$https://cloud.mongodb.com/?jmp=docs $^{42}$https://www.mongodb.com/products/mongodb-enterprise-advanced?jmp=docs 191 5.1. Administration Concepts • First, operations that occurred during the period of lag are not replicated to one or more secondaries. If you’re using replication to ensure data persistence, exceptionally long delays may impact the integrity of your data set. • Second, if the replication lag exceeds the length of the operation log ( oplog ) then MongoDB will have to perform an initial sync on the secondary, copying all data from the primary and rebuilding all indexes. This is uncommon under normal circumstances, but if you configure the oplog to be smaller than the default, the issue can arise.