Snapshot reads (atClusterTime) and history window sizing on secondaries
Parent: Long-running secondary reads in sharded clusters · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Snapshot reads (atClusterTime) and history window sizing on secondaries. 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.
How it works
- Sizing inference: budget for the age of the chosen timestamp plus the elapsed time through the last operation, including pauses between session reads. SERVER-113128 records snapshot failures when restore tests delayed their reads and extends test retention to one hour; this is test evidence, not a production sizing recommendation. (medium confidence) [source]
- Historical implementation evidence: SERVER-47672 replaced maxTargetSnapshotHistoryWindowInSeconds and removed automatic history-window adjustment intended to avoid cache pressure because durable history was available. Do not apply that older adaptive-window model to the newer parameter. (low confidence) [source]
Problems, failure modes and limitations
- The documented default history window is 300 seconds. A read or snapshot session that outlives retained history can fail with SnapshotTooOld; the window is a minimum retention setting, not a promise that arbitrary older timestamps remain readable. (high confidence) (verified as of 2026-10-14) [source]
- Do not generalize a recommendation to disable unused snapshot history to config servers. MongoDB explicitly warns that changing the default there can break internal operations, and setting minSnapshotHistoryWindowInSeconds to 0 can fail internal atClusterTime snapshot reads. (low confidence) [source]
- Alibaba documents its ApsaraDB MongoDB 5.0 parameter as defaulting to 300 seconds, changeable without restart, with an exposed range of 0–600 seconds for both replica sets and shards. This is a provider/version limit, not a universal MongoDB maximum. (low confidence) (verified as of 2026-07-31) [source]
- A December 2025 practitioner account reports lower IOPS after reducing the history window from 300 to 5 seconds during a MongoDB 4.4-to-5.0 upgrade. It gives no quantified benchmark; it cannot justify that short window for long-running historical reads. (low confidence) [source]
- minSnapshotHistoryWindowInSeconds controls the minimum retained snapshot-history window. A request whose atClusterTime is no longer in the serving server history can fail with SnapshotTooOld (239). (high confidence) [source]
- Cloud.ru Managed DocumentDB exposes minSnapshotHistoryWindowInSeconds for the shard component with an integer range of 0 to 86400 seconds. This is a provider control-plane limit, not an upstream MongoDB maximum. (low confidence) (verified as of 2026-10-30) [source]
Comparisons and alternatives
- Sizing inference: budget for the age of an explicitly selected snapshot plus elapsed query or multi-query session time, with operational margin. For a session that selects its initial snapshot, measure from its first operation to its last, rather than timing each query separately. (medium confidence) [source]
Facts and statements
- MongoDB 5.0 introduced snapshot reads outside transactions on primaries and secondaries, including sharded clusters. They read majority-committed data at one point in time across shards; supported commands include find and aggregate, with distinct restricted to unsharded collections. (high confidence) [source]
- An explicit atClusterTime requests data at timestamp T. If the selected secondary has not reached T, mongod waits; maxTimeMS can bound this wait. Without explicit atClusterTime, a delayed member can return stale majority-committed data. (low confidence) [source]
- A snapshot session reuses its initial snapshot timestamp for subsequent reads. Snapshot sessions and causal consistency are mutually exclusive; do not combine atClusterTime snapshot reads with a causally consistent session. (high confidence) [source]
- For self-managed mongod, minSnapshotHistoryWindowInSeconds supports startup and runtime configuration. The documented runtime example is db.adminCommand({setParameter:1,minSnapshotHistoryWindowInSeconds:600}). (high confidence) [source]
- Longer history retention increases disk usage for older modified values. Alibaba Cloud also warns about additional memory and performance costs, especially with frequent updates to the same document; no universal retention-to-capacity ratio is established by these sources. (high confidence) [source]
- MongoDB documentation directs Atlas users to Atlas Support to change minSnapshotHistoryWindowInSeconds. Confirm that deployment-specific path before treating the self-managed setParameter example as an Atlas procedure. (high confidence) (verified as of 2026-10-14) [source]
- Cloud.ru Managed DocumentDB exposes minSnapshotHistoryWindowInSeconds as a shard parameter and defines it as the minimum snapshot-history retention period in seconds. This independently documents the provider-facing retention control, not upstream secondary-read correctness. (low confidence) [source]
- MongoDB 5.0 introduced snapshot reads outside transactions on primaries and secondaries, including sharded clusters. They return majority-committed data at one point in time across shards. (high confidence) [source]
- Outside transactions, snapshot read concern supports find and aggregate; distinct supports it only on unsharded collections. Secondary routing alone does not select snapshot isolation. (high confidence) [source]
- A snapshot session reuses one snapshot timestamp for its related reads. Without a supplied snapshot time, the driver saves the first supported read response atClusterTime and sends it on subsequent reads. (high confidence) [source]
- Snapshot sessions and causal consistency are mutually exclusive. Explicit atClusterTime is prohibited inside causally consistent sessions. (high confidence) [source]
- The MongoDB manual and Alibaba Cloud tuning guide document a default snapshot-history window of 300 seconds. Cloud.ru independently documents the same default for its shard parameter. (high confidence) (verified as of 2026-10-30) [source]
- For self-managed MongoDB, minSnapshotHistoryWindowInSeconds can be set at startup or runtime; the manual demonstrates db.adminCommand({setParameter:1,minSnapshotHistoryWindowInSeconds:600}). The manual directs Atlas users to Atlas Support to change it. (high confidence) (verified as of 2026-10-14) [source]
Children
- No children recorded.