Context
MongoDB's oplog records replication operations in a rolling history. A disconnected secondary needs relevant history to catch up. The oplog window is the time between its oldest and newest retained entries, so the same configured storage can cover very different durations under different write workloads. Plan using observed history and recovery behavior, not capacity alone.
Prerequisites
Collect the MongoDB version, replica-set layout, oplog configuration, write-intensive job schedule, maintenance plans, and available storage. Identify which members can provide a healthy synchronization source. Obtain authorized diagnostic access. If using a managed deployment, check which commands and resizing controls are supported for its tier. Keep data-directory operations out of routine diagnostics; a member resync is a separate, destructive recovery procedure.
Measure the recovery margin
- Inspect oplog history with
rs.printReplicationInfo()for manual review ordb.getReplicationInfo()for structured automation. Record the measurement time and member identity. A status report from a quiet period does not establish the history available during an import. Capture a trend spanning representative workload cycles. - Compare the secondary's replication state with available history. Determine its last progress, disconnection duration, and the age of the operations it still needs. Include the time required to catch up after connectivity returns. A maintenance window ending before the measured oplog window is useful context, but it is not a guarantee if write rates change substantially.
- Examine workloads that generate many operations without much database growth. Updates and deletes can consume oplog history even when collection sizes appear stable. Correlate import, cleanup, and bulk-update periods with shrinking time coverage. Size planning should use observed operation generation and storage headroom rather than only business-data volume.
- Define an escalation path for a member that can no longer catch up. Preserve diagnostics and confirm the state with the database owner. Select the documented resynchronization procedure using an up-to-date source, protect voting availability, and schedule the resource load. Do not delete a member's data directory as an exploratory troubleshooting step.
Diagnostic table
| Observation | Meaning | Planning response |
|---|---|---|
| Window shrinks during bulk updates | History turns over faster | Include burst workload in capacity review |
| Database size stable, oplog busy | Changes do not require net growth | Measure operation volume |
| Secondary reconnects but falls further behind | Catch-up rate is insufficient | Investigate resource and network limits |
| Required history no longer exists | Normal catch-up cannot complete | Follow approved resync procedure |
Illustrative scenario
A secondary is paused for maintenance during a large cleanup job. The cleanup deletes many records, so the database shrinks while the oplog turns over rapidly. When the member returns, its required history is unavailable. The team schedules a controlled resync and revises maintenance planning to account for cleanup periods. A forecast based only on database size would have missed the risk.
Correct and verify
For capacity changes, use the supported procedure for the installed version and check disk headroom. For an impaired secondary, verify sustained catch-up under representative writes before declaring recovery. Confirm member state, replication progress, and stable history coverage after maintenance. If resynchronization is required, verify the source and voting plan independently before beginning.
Operating procedure
Monitor oplog time coverage, replication delay, and write-burst schedules together. Keep an owner and recovery plan for every intentionally disconnected member. Review coverage before maintenance and after workload changes. Store structured samples with timestamps so the next operator can distinguish a transient narrow window from a persistently inadequate recovery margin.
Explore Clouvenix database administration for implementation and operational handover.