MongoDB Documentation, Release 3.0.4 Avoid Replica Set Rollbacks For replica sets, the default write concern {w: 1} (page 130) only provides acknowl- edgement of write operations on the primary. With the default write concern, data may be rolled back if the primary steps down before the write operations have replicated to any of the secondaries. To prevent rollbacks of data that have been acknowledged to the client, use w: majority write concern (page 130) to guarantee that the write operations propagate to a majority of the replica set nodes before returning with acknowledge- ment to the issuing client. Rollback Limitations A mongod instance will not rollback more than 300 megabytes of data. If your system must rollback more than 300 megabytes, you must manually intervene to recover the data. If this is the case, the following line will appear in your mongod log: [replica set sync] replSet syncThread: 13410 replSet too much data to roll back In this situation, save the data directly or force the member to perform an initial sync. To force initial sync, sync from a “current” member of the set by deleting the content of the dbPath directory for the member that requires a larger rollback. Replica Set High Availability (page 580) and Replica Set Elections (page 580). From the perspective of a client application, whether a MongoDB instance is running as a single server (i.e. “stan- dalone”) or a replica set is transparent. By default, in MongoDB, read operations to a replica set return results from the primary (page 564). Users may configure read preference on a per-connection basis to prefer that the read operations return results from the secondary members. If clients configure the read preference to permit secondary reads, read operations can return data from secondary members that have not replicated more recent write operations. This behavior is sometimes characterized as eventual consistency because the secondary member’s state will eventually reflect the primary’s state and MongoDB cannot guarantee strict consistency for read operations from secondary members. 11 11 In some circumstances, two nodes in a replica set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with {w: majority} write concern (page 130). The node that can complete {w: majority} (page 130) writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition . When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary (page 657). 9.2. Replication Concepts 585 • In MongoDB, clients can see the results of writes before they are made durable: – Regardless of write concern (page 130), other clients can see the result of the write operations before the write operation is acknowledged to the issuing client. – Clients can read data which may be subsequently rolled back (page 584). • Sharded clusters where the shards are also replica sets provide the same operational semantics with regards to write and read operations. • Regardless of write concern (page 130), other clients can see the result of the write operations before the write operation is acknowledged to the issuing client. • Clients can read data which may be subsequently rolled back (page 584). Note: See also: 9.2.4 Replica Set Read and Write Semantics Note: