MongoDB Documentation, Release 3.0.4 Changed in version 3.0: When the clone process omits an invalid document from the sync, MongoDB writes a message to the logs that begins with Cloner: found corrupt document in <collection> . To perform an initial sync, see Resync a Member of a Replica Set (page 633). Replica set members replicate data continuously after the initial sync. This process keeps the members up to date with all changes to the replica set’s data. In most cases, secondaries synchronize from the primary. Secondaries may automatically change their sync targets if needed based on changes in the ping time and state of other members’ replication. For a member to sync from another, both members must have the same value for the buildIndexes setting. Beginning in version 2.2, secondaries avoid syncing from delayed members (page 570) and hidden members (page 569). In a replica set, the set can have at most one primary and only the primary can accept write operations. 17 Secondaries apply operations from the primary asynchronously to provide eventual consistency . Journaling provides single-instance write durability. Without journaling, if a MongoDB instance terminates ungrace- fully, you must assume that the database is in an invalid state. In MongoDB, clients can see the results of writes before they are made durable: MongoDB applies write operations in batches using multiple threads to improve concurrency. MongoDB groups batches by namespace and applies operations using a group of threads, but always applies the write operations to a namespace in order. While applying a batch, MongoDB blocks all reads. As a result, secondaries can never return data that reflects a state that never existed on the primary. Multithreaded Replication Validity and Durability Replication When the mongod finishes building all index builds, the member can transition to a normal state, i.e. secondary . 2. Applies all changes to the data set. Using the oplog from the source, the mongod updates its data set to reflect the current state of the replica set. 3. Builds all indexes on all collections (except _id indexes, which were already completed). • 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). 17 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). 595 9.2. Replication Concepts