# Rolling resync (initial sync) as a space-reclaim technique on Atlas > Source-anchored research for Rolling resync (initial sync) as a space-reclaim technique on Atlas. Run status: COMPLETED. Parent: [Atlas storage auto-scaling and disk reclaim via compact](https://llms-explorer.com/tree/atlas-storage-auto-scaling-and-disk-reclaim-via-compact/) · 5 facets · 17 facts · page: https://llms-explorer.com/tree/rolling-resync-initial-sync-as-a-space-reclaim-technique-on-atlas/ ## Definitions - Resyncing a replica-set member is a documented way to reclaim fragmented database-file space after deletions. MongoDB's WiredTiger storage FAQ, Percona's fragmentation advisor, and Cisco's CPS operations procedure independently describe this use; the latter two concern their own deployments and do not establish an Atlas procedure. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/storage.md) ## How it works - Cisco CPS Operations Guide 24.2.0 explicitly describes member resync as a way to reduce fragmentation and reclaim disk space. Its procedure requires an available primary and stops the target server before clearing its data directory. This is independent evidence for the self-managed mechanism, not authorization or instructions for Atlas. (low confidence) — [source](https://www.cisco.com/c/en/us/td/docs/wireless/quantum-policy-suite/R24-2-0/CPS-OperationsGuide/cps24-2-0operationsguide.pdf) - A self-managed resync destroys the destination member's existing dbPath contents and requires an accessible, up-to-date source. MongoDB warns that resyncing from stale data can undo majority-commit guarantees and cause data loss; Cisco separately requires an available primary during its resync procedure. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/resync-replica-set-member.md) - Inference: a routine Atlas scaling or node-replacement operation must not be advertised as guaranteed defragmentation merely because it performs an initial sync. Atlas may copy a snapshot or files, whereas the logical reclaim rationale depends on rebuilding documents and indexes. Confirm the actual sync method and measure the result before relying on space savings. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/scale-cluster.md) ## Problems, failure modes and limitations - The Cloud Manager rolling-resync recipe cannot be copied verbatim onto Atlas: it waits for rs.stepDown(), while MongoDB's Atlas-specific guidance says Atlas does not support rs.stepDown() or member-priority changes. This evidence scopes the self-managed recipe; it does not establish whether Atlas Support offers a managed logical-resync workflow. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/mongocli/current/command/mongocli-cloud-manager-clusters-resync.md) ## Comparisons and alternatives - Logical initial sync scans source collections, inserts their documents into new destination collections, builds their indexes, and applies buffered oplog changes. Combined with MongoDB's documented resync-based reclaim method, this explains why a logical rebuild can remove historical free space rather than preserve the source file layout; it does not guarantee an exact final size. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - Atlas documents cloud-based initial sync as creating a source-node snapshot and restoring it to a new node. Its scaling documentation says Atlas Core NVMe clusters use file-copy-based initial sync whenever initial sync is required. Both differ from the document-and-index rebuild performed by logical initial sync. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/scale-cluster.md) ## Facts and statements - Resyncing a replica-set member can reclaim unused WiredTiger file space that deletions leave available for internal reuse. Percona documents rolling node resync as an alternative to per-collection compaction. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/storage.md) - Atlas cloud-based initial sync restores a cloud-provider snapshot, whereas logical initial sync scans documents and rebuilds indexes. Therefore, do not assume that an Atlas node replacement or any operation called initial sync will reclaim fragmentation; verify which sync method it uses. This reclaim caution is an inference from the documented mechanisms. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - The documented mongocli rolling-resync commands belong to Cloud Manager and Ops Manager. They resync secondaries, wait for an operator-requested primary stepdown, and then resync the former primary; they remove the contents of each target dbPath. These pages do not establish an Atlas command or Atlas customer access to dbPath. (medium confidence) — [source](https://www.mongodb.com/docs/mongocli/current/command/mongocli-cloud-manager-clusters-resync.md) - Initial sync needs temporary local-database space for oplog records and a source oplog window long enough to cover synchronization; missing required oplog history can force a restart. A member in initial sync does not acknowledge writes. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - Treat rolling resync as a capacity and availability operation, not a guarantee of zero application impact: Percona warns that large datasets can take a long time, and MongoDB documents source-primary performance reduction during initial sync on NVMe clusters. (medium confidence) — [source](https://docs.percona.com/percona-monitoring-and-management/3/advisors/checks/mongodb-collections-fragmented.html) - The Atlas cluster-modification documentation states that Atlas Core NVMe clusters use file-copy-based initial sync whenever initial sync is required. A tier change on such a cluster should therefore not be presented as a verified logical rebuild for reclaiming fragmentation. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/scale-cluster.md) - For self-managed rolling resync, rotate only one member at a time to preserve the write quorum. MongoDB's Cloud Manager CLI documents initial-syncing secondaries in rolling order, waiting for an operator-requested primary stepdown, then initial-syncing the former primary. These are self-managed and Cloud Manager instructions, not evidence of an Atlas resync command. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/tutorial/resync-replica-set-member.md) - Logical initial sync needs temporary disk space for buffered oplog records in the destination local database and a source oplog window sufficient for catch-up. If catch-up detects an oplog continuity gap, the initial sync must restart from the beginning. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - Rolling execution does not guarantee zero application impact. MongoDB warns that initial sync adds traffic and load to the source; Atlas warns that migrations can affect a busy primary and secondary-read capacity. Percona also notes that rolling resync can take substantial time for large datasets. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/resync-replica-set-member.md) - MongoDB's Atlas scaling workflow migrates secondaries before the primary, one node at a time per replica set. Its availability guidance recommends retryable writes for primary elections. This supports planning for an election during a managed rolling operation, but does not establish a user-triggered Atlas logical-resync feature. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/scale-cluster.md)