Orphaned documents and read concern available versus local
Parent: Long-running secondary reads in sharded clusters · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Orphaned documents and read concern available versus local. 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.
Definitions
- Available is not a reliable exhaustive orphan inventory by itself: SERVER-69219 records that shard-key predicates can target only a subset of shards and thereby miss unowned documents on other shards. The ticket's 2023 resolution rejected changing all such reads to broadcasts. (low confidence) [source]
Structure and components
- For covered queries issued through mongos on sharded collections, MongoDB documents that the index must contain the shard key. Historical SERVER-8405 explains the ownership-check problem that motivates index-based chunk membership checks when the shard key is present. (medium confidence) [source]
How it works
- Do not use an apparently covered execution path as proof of correct orphan filtering: SERVER-14304 records an _id equality/projection optimization that bypassed the sharding filter and returned incorrect or duplicated results in MongoDB 2.6.0–2.6.2; the recorded fix shipped in 2.6.3. This is historical evidence, not a claim that modern releases retain that bug. (low confidence) [source]
Problems, failure modes and limitations
- MongoDB documents that an index covering a sharded query through mongos must include the shard key and all fields needed internally for sharding. Together with the documented orphan risk of available, this implies that an index-only access plan is not sufficient evidence of ownership-correct results; changing read concern to improve coverage changes the correctness assumptions. (medium confidence) [source]
Comparisons and alternatives
- For unsharded collections, including standalone and replica-set deployments, local and available behave identically. The shard-ownership tradeoff therefore must not be generalized to every MongoDB read. (high confidence) [source]
Facts and statements
- Huawei Cloud describes orphaned documents as documents remaining on one shard while their chunks exist on another shard, including after failed migrations or incomplete migration cleanup following an abnormal shutdown. (medium confidence) [source]
- For sharded collections, read concern available does not require confirmation that the receiving shard is the authoritative owner. During a partition involving chunk migration, it can return orphaned documents and incorrect or unexpected results. This is a possibility, not a guarantee that every available read returns orphans. (high confidence) [source]
- Huawei's diagnostic procedure uses find().readPref('secondary').readConcern('local').explain('executionStats') and inspects SHARDING_FILTER.chunkSkips. Alibaba independently documents the same method for ApsaraDB MongoDB 5.0 and earlier. These counts describe documents rejected during that scan, and should not be generalized from a selective query to the whole collection. (medium confidence) [source]
- Available and local behave identically for unsharded collections; available does not guarantee majority persistence, so choosing local for ownership filtering must not be confused with obtaining majority durability. (medium confidence) [source]
- For ordinary reads routed through mongos, MongoDB documents local as an alternative that avoids returning orphaned documents. All shard replica-set members maintain chunk metadata for filtering; the server replication README explains that local can wait for stale routing metadata to refresh, whereas available does not wait for that refresh. (high confidence) [source]
- Avoiding orphaned results with local does not establish majority durability: both local and available can return data that has not reached a majority of replica-set members and may subsequently roll back. (high confidence) [source]
- Huawei Cloud and Alibaba Cloud document a diagnostic through mongos using find().readPref("secondary").readConcern("local").explain("executionStats") and inspecting SHARDING_FILTER.chunkSkips for orphaned records rejected on each shard. Alibaba scopes this particular method to MongoDB 5.0 or earlier instances. Both warn that the unfiltered diagnostic scans documents across shards, so its cost can be substantial. Treat it as their documented diagnostic, not a universal explain-output contract for every server version. (medium confidence) [source]
- Ownership filtering and physical cleanup are separate operations: local-read explain diagnostics can count skipped orphaned records while those records still exist on disk, and both cloud-provider guides describe separate cleanup procedures. Selecting local does not itself delete orphaned documents. (medium confidence) [source]
Children
- No children recorded.