MongoDB rolling index builds
Parent: Resumable index builds · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for MongoDB rolling index builds. 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
- MongoDB warns against running rolling and replicated index build processes concurrently because this can cause broken builds and crash loops. (medium confidence) [source]
- SERVER-71769 records historical Atlas cases where secondaries already had an index absent from the primary, suspected to follow interrupted rolling builds; retrying on the primary could stall when those secondaries skipped commit-quorum voting. This issue report is historical evidence, not proof that every current release has the same behavior. (low confidence) [source]
- Percona demonstrated an Operator-specific maintenance workflow using /data/db/sleep-forever to prevent normal mongod restart, followed by a manual standalone build; removing the marker after shutdown restores normal pod behavior. This is a published implementation example, not a universal Kubernetes mechanism. (low confidence) (verified as of 2025-07-28) [source]
Problems, failure modes and limitations
- Creating a unique index with the manual rolling procedure requires stopping all writes to that collection throughout the procedure; if writes cannot stop, MongoDB instructs users to use the ordinary createIndex route instead. (low confidence) [source]
Facts and statements
- A rolling index build builds on one member at a time as a standalone, starting with secondaries; after replication catches up, repeat for other members and step down the original primary before building there. (high confidence) [source]
- Rolling builds can reduce index-construction resource contention on serving members, but require at least one election, lower cluster resilience, and increase total build duration; they do not guarantee zero disruption. (medium confidence) [source]
- The replica-set rolling procedure requires an oplog window long enough to cover the offline index build and allow catch-up; wait for the member to catch up before taking another member through the procedure. (high confidence) [source]
- If a standalone mongod shuts down during an index build, the build job and its progress are lost. Restarting mongod does not restart that build; createIndex must be issued again. Applied to rolling construction, this means an interrupted local build is not checkpoint-resumable. (medium confidence) (verified as of 2026-10-30) [source]
- Restarting a replica-set member as standalone does not resume its previously interrupted replicated index build: MongoDB documents that the build remains paused until manually dropped. Switching to standalone is therefore not a recovery procedure for that in-flight build. (low confidence) (verified as of 2026-10-30) [source]
- JAVA-6023 explains that the Java driver's 'Expecting replica set member, but found a STANDALONE' log during a rolling build can reflect the expected temporary topology change; that message itself does not throw an exception. (low confidence) [source]
- The official replica-set procedure hides the selected secondary with priority zero, starts it without replSetName on a different port, builds the index, restores its replica-set configuration, then restores visibility and its original priority after catch-up. (low confidence) [source]
- After processing every member, checking getIndexes on each member verifies that the rolling procedure installed the intended index everywhere. (low confidence) [source]
Children
- Oplog retention during rolling index maintenance (frontier)
- Interrupted standalone index builds (frontier)
- Index consistency after partial rolling deployment (frontier)
Frontier under this node: Index consistency after partial rolling deployment, Interrupted standalone index builds, Oplog retention during rolling index maintenance