Atlas Search index rebuild after migration
Parent: Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Atlas Search index rebuild after migration. 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.
How it works
- Resharding requires version-specific planning. The Search FAQ says resharding removes existing search indexes and requires manual rebuilding; SERVER-120851 instead records a protective change to abort resharding when search indexes exist and require users to drop them first. The issue lists fix version 9.0.0-rc0 and requested backports, not proof of every deployed Atlas version. (medium confidence) (verified as of 2026-10-31) [source]
- TCO implication, inferred from the documented behavior: budget destination index provisioning and validation work, temporary rebuild resources, source-read load when full initial indexing is required, and the interval before destination search becomes usable. Do not treat document-migration completion as proof of search readiness or apply the reported snapshot speedup as a migration-wide savings multiplier. (medium confidence) [source]
Measurements and reference values
- Manning recommends free disk space of at least 125% of the current index size for background reindexing. This is headroom for replacing an existing index, not a universal estimate for an empty destination cluster. (low confidence) [source]
Problems, failure modes and limitations
- An index-definition update builds a replacement in the background while the old index serves queries. A newly created destination index has no such old generation and cannot serve queries until its first build completes. Rebuild availability therefore depends on the operation. (high confidence) (verified as of 2026-10-31) [source]
- Check the replacement definition and generation as well as queryability before accepting an index update. KnownPath records a concrete failure mode: an existing index name and a queryable old generation did not establish that the required tenant-filter definition was current. Its remediation required the latest generation to be READY and queryable. (medium confidence) (verified as of 2026-10-31) [source]
- LightRAG issue 3978 reports a separate recovery pitfall: its MongoDB adapter deleted documents but retained the Atlas search-index definition, causing a dimension guard to fail again during recovery. The issue calls for explicit index replacement in that application path. This is evidence about application recovery tooling, not proof that ordinary cluster migrations require embedding regeneration. (low confidence) (verified as of 2026-10-31) [source]
Comparisons and alternatives
- For M10+ dedicated clusters, Cloud Backup restores search-index definitions rather than search-index data. mongot then initial-syncs the restored definitions; large indexes can delay restoration. This path differs from mongosync, which does not synchronize Search indexes. (high confidence) (verified as of 2026-10-31) [source]
Facts and statements
- mongosync does not synchronize Atlas Search indexes. Destination search-index creation and readiness therefore need a separate migration step; copying collection data is insufficient. (high confidence) (verified as of 2026-10-31) [source]
- A reply in MongoDB's community forum advised building destination search indexes after live-migration cutover in October 2024. Building during synchronization was possible, but did not guarantee consistent search results immediately after cutover. This is dated migration guidance, not evidence of a universal 2026 rebuild rule. (low confidence) (verified as of 2026-10-31) [source]
- Search Node scaling need not always rebuild indexes by rereading the entire source collection. MongoDB documents reuse of recent object-storage index copies for eligible dedicated Search Nodes without customer-managed Encryption at Rest; the AWS/MongoDB implementation description explains snapshot download and catch-up, with full rebuild fallback if download fails. These mechanisms do not establish cross-cluster live-migration index transfer. (high confidence) (verified as of 2026-10-31) [source]
- A migration TCO estimate should budget destination index construction, readiness checks and search validation separately from database transfer. Sources establish these activities but do not supply a general rebuild duration or dollar cost; measure them on the intended corpus and index definition. This is a planning inference. (medium confidence) [source]
- Atlas live migration does not migrate MongoDB Search indexes from the source cluster to the destination. Destination Search index creation must be planned separately from document migration. (high confidence) (verified as of 2026-10-31) [source]
- The April 2, 2025 AWS/MongoDB article reports a 14-fold index reconstruction speed improvement in MongoDB internal tests using S3 snapshots. It does not provide an independently reproduced migration benchmark or a guaranteed cross-cluster cutover duration. (low confidence) (verified as of 2026-10-31) [source]
Children
- No children recorded.