# Rolling index builds as a resource-isolation alternative > Source-anchored research for Rolling index builds as a resource-isolation alternative. Run status: COMPLETED. Parent: [Index build resource limits (maxNumActiveUserIndexBuilds, disk space)](https://llms-explorer.com/tree/index-build-resource-limits-maxnumactiveuserindexbuilds-disk-space/) · 5 facets · 16 facts · page: https://llms-explorer.com/tree/rolling-index-builds-as-a-resource-isolation-alternative/ ## How it works - MongoDB warns against overlapping rolling index builds with replicated index builds because the combination can cause broken builds and crash loops. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - Percona demonstrated an operator-specific Kubernetes workflow because simply stopping mongod can trigger pod health-check replacement; its example uses the sleep-forever mechanism before starting the member as a standalone. (low confidence) — [source](https://www.percona.com/blog/how-to-perform-rolling-index-builds-with-percona-operator-for-mongodb/) ## Measurements and reference values - MongoDB recommends rolling builds only for deployments with average CPU utilization above (N-1)/N-10%, where N is the number of CPU threads available to mongod, or a WiredTiger cache fill ratio regularly above 90%; otherwise it recommends the default build. These are documented selection criteria, not benchmark guarantees. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) ## Problems, failure modes and limitations - For a manual rolling unique-index build, stop all writes to the collection throughout the procedure; if writes cannot stop, MongoDB directs users to create the unique index through the primary instead. (low confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md) - MongoDB’s 2025 Compass copy-change ticket explicitly replaced encouraging language with a warning about lower resilience and longer build times, recommending rolling builds only when regular builds do not meet requirements. (high confidence) — [source](https://jira.mongodb.org/browse/COMPASS-9519) - For unique indexes, the rolling procedure requires stopping all writes to the target collection throughout the procedure. If writes cannot stop, MongoDB directs operators to create the index through the replica-set primary or, for sharded deployments, through mongos instead. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md) ## Comparisons and alternatives - A rolling build lowers cluster resilience and increases overall build duration. Keeping a member unavailable for construction is an availability tradeoff, even when the remaining members continue serving traffic. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - The sharded-cluster procedure disables migrations for the collection with setAllowMigrations before identifying and processing its shards, and warns against concurrent DDL operations. Use the sharded procedure rather than applying replica-set instructions unchanged. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-sharded-clusters.md) ## Facts and statements - Rolling builds construct an index on one isolated member at a time, beginning with secondaries; that member runs as a standalone and then rejoins the replica set. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - The resource-isolation benefit is conditional: moving construction off serving members can reduce production CPU and I/O contention on deployments already near capacity; the sources do not establish a universal zero-impact guarantee. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - Rolling builds reduce cluster resilience and increase total build duration; the original primary must step down so the procedure includes a replica-set election. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - The oplog must retain enough history to cover the offline indexing interval and permit the member to catch up. Confirm catch-up before taking the next secondary through the procedure. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md) - A documented incident associated a bad rolling-build procedure with delayed reads from a lagged secondary; MongoDB’s procedure hides the member and waits for catch-up before unhiding it. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-97783) - ScaleGrid reported in February 2017 that its own UI and backend orchestrated rolling index builds server by server; that historical implementation report is not evidence of current product availability. (low confidence) — [source](https://scalegrid.io/blog/the-perils-of-building-indexes-on-mongodb/) - Rolling builds construct the index sequentially on individual members as standalones, separating build work from the members currently serving the application. This may reduce production performance impact; it does not eliminate the work of building the index. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/rolling-index-builds.md) - For a replica set, build on secondaries one at a time, restore each member and let replication catch up before proceeding, then step down the original primary and build on that former primary. The procedure therefore includes a replica-set election. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets.md)