Replica set oplog window and initial sync
Parent: Rolling index builds · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Replica set oplog window and initial sync. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Initial sync adds traffic and load to its source. Schedule resynchronization when bandwidth and workload permit; cloning includes index construction, so index footprint forms part of initial-sync work. (high confidence) [source]
How it works
- Kevin Adistambha's October 2020 forum explanation dates concurrent oplog tailing during the clone phase to MongoDB 3.4. Current documentation and implementation descriptions support the buffering mechanism, so pre-3.4 whole-copy-window guidance needs historical qualification. (high confidence) [source]
Problems, failure modes and limitations
- The oplog window measures retained history in time. If all eligible sync sources have overwritten entries a secondary still needs, ordinary replication cannot catch up and a full resynchronization is required. (high confidence) [source]
- If a secondary's required replication position predates the oldest oplog entry on every eligible sync source, ordinary oplog replication cannot catch it up. MongoDB's replication implementation describes rejecting sources that are too far ahead and requiring manual intervention when all candidates are too far ahead; Percona identifies initial sync as the recovery route for a secondary that exceeds the retained window. (medium confidence) [source]
- A larger oplog does not guarantee initial-sync success. MongoDB checks operation continuity and source rollback, and persistent failures can restart the attempt. Retention capacity therefore cannot substitute for diagnosing network failures, source rollback, or insufficient destination resources. (medium confidence) [source]
Comparisons and alternatives
- Treat 'the entire initial sync must finish within one source oplog window' as an oversimplification for collection-buffered logical initial sync. MongoDB describes concurrent fetching during cloning and continued fetching during oplog application; its manual specifically requires sufficient history for continuity during application. Operationally, preserve access to every entry still needed from the source and provision buffer space, rather than using total clone elapsed time alone as a failure test. (high confidence) [source]
- The oplog window measures retained history in time, rather than merely the configured oplog capacity in bytes. Percona's monitoring documentation defines Oplog Range as the span from the oldest entry to the newest entry; its older replica-set guide also describes the window in seconds. (medium confidence) [source]
Facts and statements
- Logical initial sync clones databases other than local, builds collection indexes during cloning, and subsequently applies oplog changes. MongoDB's manual and replication implementation both describe these distinct clone and oplog-application stages. (high confidence) [source]
- Logical initial sync fetches oplog entries during data cloning and buffers them in a destination-side collection for later application. The destination needs disk space for this buffer in local; sizing only the source oplog omits a separate storage requirement. (high confidence) [source]
- The source oplog window should cover expected maintenance and downtime, and the time needed to restore a member from backup. Snapshot seed files must be recent enough for the restored member to catch up using retained oplog entries. (high confidence) [source]
- Percona PMM distinguishes oldest-to-newest Oplog Range from current-time-to-oldest Now to End, and exposes oplog generation in GB/hour. These metrics help assess retention as workload changes. (low confidence) (verified as of 2026-10-31) [source]
- AceMQ reports that nightly ETL bursts repeatedly pushed secondaries beyond retained oplog history, causing full initial syncs that competed with subsequent loads. It reports eliminating recurring nightly resyncs through oplog resizing, reduced write amplification, and staggered concurrency. This is an anonymous customer case without published raw measurements, not a general performance guarantee. (low confidence) [source]
- As an operational inference, size and alert on retained time under peak oplog generation, with headroom for disruption. Percona documents monitoring both the retained range and oplog GB/hour; AceMQ's self-reported support case describes measuring a full batch window and resizing after nightly writes exhausted retained history. (medium confidence) [source]
Children
- Initial-sync oplog buffering and destination disk sizing (frontier)
- Oplog fetch lag versus apply lag (frontier)
- Oplog retention sizing under burst writes (frontier)
Frontier under this node: Initial-sync oplog buffering and destination disk sizing, Oplog fetch lag versus apply lag, Oplog retention sizing under burst writes