# Snapshot reads on secondaries and minSnapshotHistoryWindowInSeconds > Source-anchored research for Snapshot reads on secondaries and minSnapshotHistoryWindowInSeconds. Run status: COMPLETED. Parent: [Long-running secondary reads in sharded clusters](https://llms-explorer.com/tree/long-running-secondary-reads-in-sharded-clusters/) · 5 facets · 19 facts · page: https://llms-explorer.com/tree/snapshot-reads-on-secondaries-and-minsnapshothistorywindowinseconds/ ## Structure and components - Cloud.ru's Managed DocumentDB parameter table exposes minSnapshotHistoryWindowInSeconds for shard components, with a 300-second default and a 0–86400-second range. Its managed-service range must not be substituted for another provider's limits. (low confidence) (verified as of 2026-10-30) — [source](https://cloud.ru/docs/documentdb/ug/topics/guides__parameters__available-parameters-list) ## How it works - Increasing minSnapshotHistoryWindowInSeconds increases disk usage because WiredTiger retains older modified values; the disk cost depends on the update workload. It is a retention setting, not a guarantee that every long-running query completes. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/long-running-queries.md) - A secondary that has not reached a requested atClusterTime waits to serve the snapshot read. MongoDB recommends maxTimeMS to bound that wait; majority-committed snapshot data on a delayed secondary can still be stale when no timestamp is specified. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) - A snapshot session reuses one snapshot across related reads. If the application does not supply snapshotTime in SessionOptions, the driver records the first read response’s atClusterTime and sends that timestamp on subsequent reads. Applications may instead supply snapshotTime when creating the session. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/long-running-queries.md) ## Problems, failure modes and limitations - A snapshot session preserves its snapshot timestamp across supported reads. If SessionOptions does not supply snapshotTime, drivers save atClusterTime from the first read response and send it on subsequent reads; an application may instead supply snapshotTime. Snapshot sessions cannot also request causal consistency, and startTransaction on a snapshot session must fail. (high confidence) — [source](https://specifications.readthedocs.io/en/latest/sessions/snapshot-sessions/) - Budget retention for the complete interval from the first operation to the last operation in a snapshot session, including application delays. MongoDB documents increasing minSnapshotHistoryWindowInSeconds to 600 as an example, and driver tests use the same workaround for slow snapshot tests. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/long-running-queries.md) - MongoDB warns that changing snapshot-history defaults on config-server nodes can break internal operations. In particular, do not set minSnapshotHistoryWindowInSeconds to zero on config servers, because internal snapshot reads with atClusterTime can fail. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) - Snapshot sessions and causal consistency are mutually exclusive, and starting a transaction in a snapshot session must fail. Secondary snapshot sessions therefore must not be treated as secondary read-only transactions. (low confidence) — [source](https://specifications.readthedocs.io/en/latest/sessions/snapshot-sessions/) - Alibaba Cloud's ApsaraDB for MongoDB 5.0 parameter table lists a 300-second default and an allowed range of 0–600 seconds, with no restart required. These are that managed service's documented settings, not a universal MongoDB upper limit. (low confidence) (verified as of 2026-07-31) — [source](https://www.alibabacloud.com/help/en/mongodb/user-guide/parameters-available-in-mongodb-5-0) ## Comparisons and alternatives - minSnapshotHistoryWindowInSeconds specifies the minimum retained snapshot-history window. MongoDB documents a default of 300 seconds; a requested timestamp older than available history can fail with SnapshotTooOld rather than silently reading newer data. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) - Budget the history window across the entire snapshot session, from its first read through its last, rather than giving each query an independent fresh window. Reads that outlast retained history may fail; 300 seconds is not a promise that every cursor is killed at precisely that elapsed time. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) ## Facts and statements - MongoDB 5.0 introduced read concern snapshot outside multi-document transactions on primaries and secondaries, including sharded clusters. It returns majority-committed data from a single point in time across shards. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) - Outside transactions, snapshot read concern supports find and aggregate, plus distinct only on unsharded collections; selecting a secondary alone does not request snapshot read concern. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) - In the replication implementation, reads using read concern levels other than snapshot can switch to newer snapshots after a storage-engine yield. A long-running local or majority read therefore lacks a single point-in-time view across its full execution. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - minSnapshotHistoryWindowInSeconds specifies the minimum snapshot-history retention period. The documented default is 300 seconds; an atClusterTime no longer available in history can produce SnapshotTooOld (239). A snapshot read exceeding the retained history window may terminate. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) - For a self-managed mongod, minSnapshotHistoryWindowInSeconds accepts a nonnegative integer and can be set at startup or at runtime, for example db.adminCommand({setParameter:1,minSnapshotHistoryWindowInSeconds:600}). MongoDB documents that Atlas customers must contact Atlas Support to modify this value. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/parameters.md) - Managed-service bounds are provider-specific: Alibaba Cloud documents a 0–600 second range and default 300 for its MongoDB 5.0 parameter, while Cloud.ru Managed DocumentDB documents a shard parameter range of 0–86400 and default 300. These ranges must not be generalized to self-managed MongoDB or Atlas. (high confidence) (verified as of 2026-10-30) — [source](https://www.alibabacloud.com/help/en/mongodb/user-guide/parameters-available-in-mongodb-5-0) - Outside transactions, snapshot read concern supports find and aggregate, and distinct on unsharded collections; it does not make every read command snapshot-capable. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot.md) - For self-managed deployments, MongoDB documents db.adminCommand({setParameter:1,minSnapshotHistoryWindowInSeconds:600}) to increase the window to 600 seconds. Longer retention consumes more disk for older modified values, with the cost depending on workload. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/long-running-queries.md)