Docs Menu
"snapshot"

Read Concern "snapshot"

New in version 4.0.

Changed in version 5.0.

Read concern "snapshot" is available for multi-document transactions, and starting in MongoDB 5.0, certain read operations outside of multi-document transactions.

  • If the transaction is not part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data.
  • If the transaction is part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start.

Outside of multi-document transactions, read concern "snapshot" is available on primaries and secondaries for the following read operations :

All other read commands prohibit "snapshot".

For a list of all operations that accept read concerns, see Operations That Support Read Concern.

Multi-document transactions support read concern "snapshot" as well as "local", and "majority".

Note

You set the read concern at the transaction level, not at the individual operation level. To set the read concern for transactions, see Transactions and Read Concern.

New in version 5.0.

Outside of multi-document transaction, reads with read concern "snapshot" support the optional parameter atClusterTime. The parameter atClusterTime allows you to specify the timestamp for the read. To satisfy a read request with a specified atClusterTime of T, the mongod performs the request based on the data available at time T.

You can obtain the operationTime or clusterTime of an operation from the response of db.runCommand() or from the Session() object.

The following command performs a find operation with read concern "snapshot" and specifies that the operation should read data from the snapshot at cluster time Timestamp(1613577600, 1).

db.runCommand( {
find: "restaurants",
filter: { _id: 5 },
readConcern: {
level: "snapshot",
atClusterTime: Timestamp(1613577600, 1)
},
} )

If the parameter atClusterTime is not supplied, the mongos, or in single member replica sets the mongod, selects the timestamp of the latest majority-committed snapshot as the atClusterTime and returns it to the client.

Outside of transactions, "snapshot" reads are guaranteed to read from majority-committed data.

Starting in version 5.0, you cannot use read concern "snapshot" when reading from a capped collection.

Give Feedback
© 2021 MongoDB, Inc.

About

  • Careers
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2021 MongoDB, Inc.