# orphanCleanupDelaySecs and range deletion timing > Source-anchored research for orphanCleanupDelaySecs and range deletion timing. Run status: COMPLETED. Parent: [Long-running secondary reads in sharded clusters](https://llms-explorer.com/tree/long-running-secondary-reads-in-sharded-clusters/) · 4 facets · 17 facts · page: https://llms-explorer.com/tree/orphancleanupdelaysecs-and-range-deletion-timing/ ## Structure and components - orphanCleanupDelaySecs defines a minimum delay before the source shard deletes a migrated range. In the documented current sequence, MongoDB first waits for relevant in-progress primary reads to complete, then waits an additional orphanCleanupDelaySecs; the delay is not an exact wall-clock completion deadline measured from migration commit. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) ## Problems, failure modes and limitations - Increasing orphanCleanupDelaySecs can accommodate longer secondary reads, but retains orphaned documents longer. MongoDB warns that indexed queries lacking the shard key may slow down because they must filter more orphans. (medium confidence) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) ## Comparisons and alternatives - SERVER-90242 and its duplicate SERVER-96417 describe a scheduling limitation: a stepdown/stepup can make queued deletions wait the full configured delay again, rather than crediting the task's age. The March 26, 2025 descriptions warn that failovers more frequent than a long cleanup delay can perpetually postpone deletion; they do not establish applicability to every later release. (high confidence) (verified as of 2025-03-26) — [source](https://jira.mongodb.org/browse/SERVER-90242) - SERVER-124370 reports a MongoDB 8.2/8.3 config-server transition test where migrating a previously donated range back to its former owner repeatedly hit ExceededTimeLimit while overlapping orphan deletion remained pending. The report links the one-hour default change, but is an individual incident report rather than proof that all draining transitions fail. (low confidence) (verified as of 2026-04-22) — [source](https://jira.mongodb.org/browse/SERVER-124370) ## Facts and statements - MongoDB 8.2 changed the default orphanCleanupDelaySecs from 900 seconds to 3600 seconds. The 8.3 documentation and Percona's July 30, 2026 release discussion retain the one-hour default; TencentDB's analysis of MongoDB 8.0.10 describes the earlier 900-second default. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - With the default MongoDB 8.2-and-later behavior, a secondary terminates affected reads that began before migration commit before applying orphan deletions. The grace period lets reads finish first; it does not promise that every long-running read will survive. QueryPlanKilled code 175 with the orphan range cleanup message identifies this termination. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - orphanCleanupDelaySecs can be set at startup or runtime, for example db.adminCommand({setParameter:1, orphanCleanupDelaySecs:7200}). A runtime change applies to newly created range deletions; documentation says a primary stepdown is needed to apply it to existing deletion tasks. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) - Setting _waitForDelete:true bypasses orphanCleanupDelaySecs. The current balancer documentation warns that secondary reads may terminate during deletion; the older SERVER-87673 description explains that without secondary-read termination even shorter secondary reads could silently miss documents under this option. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration.md) - The cleanup grace period must be distinguished from deletion throughput: rangeDeleterBatchSize controls documents per batch, while rangeDeleterBatchDelayMS controls pauses between batches. TencentDB's MongoDB 8.0.10 analysis describes these as separate controls, so changing orphanCleanupDelaySecs alone does not set the duration of the deletion phase. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) - On versions before 8.2, or with terminateSecondaryReadsOnOrphanCleanup:false, an affected secondary read can continue across orphan deletion and silently miss documents. Raising orphanCleanupDelaySecs reduces the opportunity for that race but does not establish correctness for arbitrarily long secondary reads. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - The documented default increased from 900 seconds to 3600 seconds in MongoDB 8.2; MongoDB 8.0 documentation still specifies 900 seconds. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - Before MongoDB 8.2, secondary reads spanning migration cleanup could silently miss documents; 8.2 introduced default read termination before replicated orphan deletions. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - orphanCleanupDelaySecs is configurable at startup and runtime; a runtime example is db.adminCommand({setParameter: 1, orphanCleanupDelaySecs: 7200}). (high confidence) — [source](https://www.mongodb.com/docs/v8.3/core/long-running-secondary-reads/) - A changed delay applies only to newly created range deletions; the parameter documentation says forcing a primary stepdown applies it to existing deletions. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/parameters/) - The balancer can start another migration before the preceding range cleanup finishes. Migration completion therefore does not establish that donor-side orphan removal has completed. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration.md) - In an independent MongoDB 8.0.32 experiment, Jin's blog observed delayed config.rangeDeletions tasks and retained donor documents after balancing, while a moveRange with waitForDelete: true removed its donor range immediately. (low confidence) (verified as of 2026-09-27) — [source](https://jinlog.dev/posts/mongodb/07-sharding/) - Percona's 8.3 Technical Preview announcement describes its distribution inheriting the longer 3600-second delay and default termination of secondary reads begun before migration commit. (low confidence) (verified as of 2026-07-30) — [source](https://www.percona.com/blog/percona-server-for-mongodb-8-3-technical-preview-is-now-available/)