方便游客 遂宁今年将新增加80座旅游厕所
Changed in version 5.0.
A query with read concern "snapshot" returns majority-committed data as it
appears across shards from a specific single point in time in the recent past.
Read concern "snapshot" provides its guarantees only if the transaction
commits with write concern "majority".
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.
Important
A "snapshot" read can only be performed within the time
period specified by minSnapshotHistoryWindowInSeconds.
A read operation that lasts longer than
minSnapshotHistoryWindowInSeconds may terminate.
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".
Operations
For a list of all operations that accept read concerns, see Operations That Support Read Concern.
Read Concern and Transactions
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.
Read Concern and atClusterTime
New in version 5.0.
Outside of multi-document transactions, 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.
atClusterTime Considerations and Behavior
The allowed values for
atClusterTimedepend on theminSnapshotHistoryWindowInSecondsparameter.minSnapshotHistoryWindowInSecondsis the minimum time window in seconds for which the storage engine keeps the snapshot history. If you specify an atClusterTime value older than the oldest snapshot retained according tominSnapshotHistoryWindowInSeconds,mongodreturns an error.If you perform a read operation with
"snapshot"against a delayed replica set member, the returned majority-committed data could be stale.It is not possible to specify
atClusterTimefor"snapshot"inside of causally consistent sessions.
Read Concern on Capped Collections
Starting in MongoDB 8.0, you can use read concern
"snapshot" on capped
collections.