# Read concern available, secondary reads and orphaned documents > Source-anchored research for Read concern available, secondary reads and orphaned documents. Run status: COMPLETED. Parent: [Covered queries on sharded collections](https://llms-explorer.com/tree/covered-queries-on-sharded-collections/) · 4 facets · 13 facts · page: https://llms-explorer.com/tree/read-concern-available-secondary-reads-and-orphaned-documents/ ## How-to and procedures - Set the intended read concern explicitly and verify deployment and server-version defaults before interpreting a secondary-read performance test. The consulted sources disagree about secondary defaults, so available must not be assumed solely from the choice of secondary read preference. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern.md) ## Problems, failure modes and limitations - Available read concern cannot be used with causally consistent sessions or transactions. It is therefore unsuitable as an optimization for a query that requires either of those execution contexts. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - Huawei Cloud documents a diagnostic through mongos using find().readPref("secondary").readConcern("local").explain("executionStats"): inspect chunkSkips under SHARDING_FILTER for skipped orphaned documents. Its page warns that this collection-wide scan can be slow and put pressure on all shards. Treat the named explain fields as a provider-documented diagnostic and verify their presence on the target server version. (low confidence) (verified as of 2025-07-24) — [source](https://support.huaweicloud.com/intl/en-us/drs_faq/drs_09_0101.html) - Inference for covered-query evaluation: choosing available cannot establish correct shard ownership merely because execution avoids document fetches. MongoDB separately requires an index to contain the shard key to cover a query on a sharded collection through mongos; keep that coverage requirement separate from read-concern guarantees. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization.md) - MongoDB replication internals explain that an available read on a shard secondary does not wait for a stale routing-table cache to refresh. The secondary can therefore serve a stale view of a chunk moved and modified on another shard; the risk is broader than a duplicate document during the migration itself. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) ## Comparisons and alternatives - For reads of sharded collections on secondary shard nodes, available can answer without waiting for stale routing metadata to refresh. It can therefore return orphaned documents or an outdated view of a chunk moved to another shard; the tradeoff is greater availability during network partitions. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - Do not infer that a sharded query became covered merely because available reduced its latency. This is a methodological inference: available changes ownership-metadata waiting, whereas coverage requires satisfying the query from an index. Inspect explain output for the actual query and index, and assess the correctness trade-off separately. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) ## Facts and statements - Read preference controls which replica-set members are eligible to serve a read; read concern controls the consistency and isolation of the returned data. Selecting a secondary does not by itself specify available read concern. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/distributed-queries.md) - For unsharded collections, available and local behave identically. Available does not guarantee majority replication or protection from rollback, and the newest data on a node need not be the newest data in the system. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - For sharded reads where orphan exclusion matters, MongoDB recommends a different read concern such as local. A secondary using local may need to refresh stale routing metadata through the shard primary or config servers before answering. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern.md) - For sharded queries, available does not require verification that the receiving shard is the authoritative owner. Following a chunk migration or during a network partition, it can return orphaned documents and incorrect or unexpected results. It also does not guarantee majority replication, so returned writes may later roll back. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - For a sharded collection queried through mongos, MongoDB documents that an index can cover the query only if it includes the shard key. Query coverage also requires the fields needed internally for sharding, the predicate fields, and returned fields to be in the index. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization.md) - A secondary may lag behind the primary regardless of the orphan-exposure issue. Available returns data from the selected instance without a guarantee that it is the latest system-wide version; index coverage does not remove replication lag. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md)