readConcern available on sharded clusters
Parent: Covered queries on sharded collections · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for readConcern available on sharded clusters. 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.
Structure and components
- MongoDB documents that a query through mongos on a sharded collection can be covered only when the covering index contains the shard key, in addition to the other query and projection fields required for coverage. (low confidence) [source]
How it works
- SERVER-86667 records a historical bug in views over sharded collections: available caused shard versions to be ignored and the collection to appear UNSHARDED to CollectionShardingRuntime, bypassing the routing kickback mechanism. The issue lists fixes in 7.3.3 and 8.0.0-rc0; this is historical evidence, not proof that current releases retain the defect. (low confidence) (verified as of 2026-10-31) [source]
- OneUptime recommends available only when the application accepts approximate results or orphan exposure, and advises avoiding it when clean ownership semantics or accuracy are required. This is the author's workload recommendation, not a benchmark demonstrating a universal throughput gain. (low confidence) (verified as of 2026-10-31) [source]
- Shard secondaries maintain chunk metadata and can filter orphaned documents when the operation does not use available. Secondary read preference alone therefore does not imply that a query must expose orphans. (medium confidence) [source]
Problems, failure modes and limitations
- The correctness risk extends beyond duplicate orphans: stale metadata can expose an old view of a migrated chunk. SERVER-90727 documents an analyzeShardKey test failure in which an available-read aggregation reached the wrong shard after balancing and found zero sampled documents. (high confidence) [source]
Comparisons and alternatives
- MongoDB documents local as an alternative that filters orphaned data. Its replication internals explain that a secondary with stale sharding metadata may need a routing-cache refresh involving the primary or config servers before serving a local read. This coordination explains why changing to available is a consistency tradeoff rather than a free performance improvement. (high confidence) [source]
- On sharded collections, available omits checks that the queried shard is the authoritative owner. During partitions and chunk migration it can return orphaned documents or unexpected results; this is a correctness tradeoff, not simply a faster equivalent of local. (medium confidence) [source]
Facts and statements
- For sharded collections, readConcern available skips both shard-version checking and orphan-document filtering. Avoiding metadata coordination can improve partition tolerance, but the receiving shard may not be the authoritative owner of the returned data. (high confidence) [source]
- For covering queries through mongos on sharded collections, the manual requires the index to include the shard key, together with the other fields needed by the query. The fact that available bypasses shard filtering is not sufficient evidence of a supported general exception; inspect the actual plan and validate ownership semantics before claiming coverage. (medium confidence) [source]
- Available reads do not require majority replication and can return data later rolled back. Alibaba Cloud independently documents the same rollback and orphan-document risks for its MongoDB service. (high confidence) [source]
- Available is unavailable for operations in causally consistent sessions and for transactions. It is therefore not a read-concern option for optimizing covered reads inside a transaction. (high confidence) [source]
- For unsharded collections, including those on standalone or replica-set deployments, available and local behave identically; the documented distinction concerns sharded collections and their metadata checks. (high confidence) [source]
- Available does not require majority replication of returned data, so the returned writes may later be rolled back. Orphan filtering and majority durability are separate guarantees: local can avoid orphans while still allowing rollback. (medium confidence) [source]
- Inference for covered-query tuning: choosing available changes ownership guarantees; the read-concern documentation does not establish that it removes the documented shard-key requirement for coverage through mongos. Do not present it as a generally supported replacement for a covering index containing the shard key. (medium confidence) [source]
- The MongoDB 8.0 defaults reference lists local for reads against both primaries and secondaries. SERVER-86745 records that older behavior used available semantics for secondary reads before the default changed to local; available should not be described as the universal modern secondary default. (medium confidence) [source]
Children
- No children recorded.