How does initial sync differ from steady-state oplog tailing in a MongoDB replica set?

## The bootstrapping problem Replication in MongoDB works by replaying an oplog — a log of changes — onto an existing copy of the data. That works only if the member already has a copy that matches some point in the log. A brand-new member has nothing. Initial sync is how it acquires that baseline. Initial sync happens automatically when a `mongod` joins a replica set with an empty `dbPath`, and it is also the standard remedy when an existing member has fallen so far behind that the entries it needs are no longer in any sync source's oplog. ## What logical initial sync does The default method is *logical* initial sync — the syncing member reads documents through the normal query interface and writes them locally. Broadly: 1. **Choose a sync source.** The member picks a reachable, sufficiently up-to-date member. It need not be the primary; a secondary is often chosen, which is desirable because cloning is heavy. 2. **Record a start point.** It notes where the source's oplog stands before cloning begins. 3. **Clone the data.** It copies every database except `local`, collection by collection, and builds the indexes for each collection as it goes. 4. **Apply the oplog written during the clone.** Cloning a large data set takes hours, and the source keeps accepting writes throughout. Those writes are pulled from the source's oplog and applied, so the member converges on a consistent snapshot rather than a smeared mixture of old and new documents. 5. **Transition to SECONDARY.** Once it has caught up, the member starts ordinary tailing. The replica set state during all of this is `STARTUP2`, which is how you tell from `rs.status()` that a member is syncing rather than merely lagging. ## Failure and resumability Historically an interrupted initial sync had to start over from zero — brutal on a multi-terabyte data set. Recent versions can resume after transient network failures within a bounded retry period, and will restart the attempt a limited number of times before giving up. MongoDB Enterprise also offers a **file-copy-based** initial sync (selected with the `initialSyncMethod` parameter) that copies the storage-engine files directly instead of reading documents; it is typically faster on large data sets but has its own constraints. ## Steady-state tailing Once it is a `SECONDARY`, the member's behaviour is completely different in shape. It holds a tailing cursor open against the sync source's `oplog.rs` and receives batches of new entries as they are written. It applies each batch using several writer threads in parallel, preserving order per document, then records its progress so the primary and the rest of the set can see how current it is. The sync source is not fixed. If chained replication is enabled — it is by default, via the `chainingAllowed` setting — a secondary may sync from another secondary that is ahead of it, and it will change source if its current one becomes unsuitable. ## Comparing the two | | Initial sync | Steady-state tailing | |---|---|---| | Trigger | Empty `dbPath`, or a member too stale to catch up | Normal operation of a `SECONDARY` | | Data moved | The entire data set | Only new oplog entries | | Duration | Hours to days at scale | Continuous | | Cost driver | Total data size and index build time | Write rate on the primary | | Member state | `STARTUP2` | `SECONDARY` | ## Operational consequences The practical point is that initial sync is *expensive*, and every design decision that makes it more likely — undersized oplogs, long maintenance windows, aggressive restarts — buys you a multi-hour whole-data-set transfer at the least convenient moment. Choosing a secondary as the sync source, or seeding a new member's `dbPath` from a recent snapshot of another member so it only needs to tail rather than clone, are the usual ways to keep the primary out of harm's way. Initial sync also builds every index from scratch, which on an index-heavy collection can dominate the elapsed time — so index count, not just data size, is part of the cost.