Read Concern¶

Read Concern Option¶

For operations not in multi-document transactions, you can specify a readConcern level as an option to commands and methods that support read concern:

readConcern: { level: <level> }

To specify the read concern level for the mongo shell method db.collection.find(), use the cursor.readConcern() method:

db.collection.find().readConcern(<level>)

Transactions and Available Read Concerns¶

For multi-document transactions, you set the read concern at the transaction level, not at the individual operation level. The operations in the transaction will use the transaction-level read concern. Any read concern set at the collection and database level is ignored inside the transaction. If the transaction-level read concern is explicitly specified, the client level read concern is also ignored inside the transaction.

You can set the read concern at the transaction start:

• For multi-document transaction, the following read concern levels are available:
  • "local"
  • "majority"
  • "snapshot"
• Write commands that are part of a multi-document transactions can support the transaction-level read concern.
• Starting in MongoDB 4.4, with feature compatibility version (fcv) "4.4" or greater, you can create collections and indexes inside a transaction. If explicitly creating a collection or an index, the transaction must use read concern "local". Implicit creation of a collection can use any of the read concerns available for transactions.

If unspecified at the transaction start, transactions use the session-level read concern or, if that is unset, the client-level read concern.

For more information, see Transaction Read Concern.

Causally Consistent Sessions and Available Read Concerns¶

For operations in a causally consistent session, "local" and "majority" levels are available. However, to guarantee causal consistency, you must use "majority". For details, see Causal Consistency.

If a multi-document transaction is associated with a causally consistent session, "snapshot" is also available for the the transaction.

Operations That Support Read Concern¶

The following operations support read concern:

The following write operations can also accept a read concern if part of a multi-document transaction:

Read Concern not Supported on local Database¶

The local database does not support read concerns. MongoDB silently ignores any configured read concern for an operation on a collection in the local database.

Read Your Own Writes¶

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.

Prior to MongoDB 3.6, in order to read your own writes you must issue your write operation with { w: "majority" } write concern, and then issue your read operation with primary read preference, and either "majority" or "linearizable" read concern.

Real Time Order¶

Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.

Performance Comparisons¶

Unlike "majority", "linearizable" read concern confirms with secondary members that the read operation is reading from a primary that is capable of confirming writes with { w: "majority" } write concern. [4] As such, reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns.

Always use maxTimeMS with linearizable read concern in case a majority of data bearing members are unavailable. maxTimeMS ensures that the operation does not block indefinitely and instead ensures that the operation returns an error if the read concern cannot be fulfilled.

For example:例如：

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)

db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )

Read Operations and afterClusterTime¶

MongoDB 3.6 introduces support for causally consistent sessions. For read operations associated with causally consistent session, MongoDB 3.6 introduces the afterClusterTime read concern option to be set automatically by the drivers for operations associated with causally consistent sessions.

To satisfy a read request with an afterClusterTime value of T, a mongod must perform the request after its oplog reaches time T. If its oplog has not reached time T, the mongod must wait to service the request.

Read operations with a specified afterClusterTime return data that meet both the read concern level requirement and the specified afterClusterTime requirement.

For read operations not associated with causally consistent sessions, afterClusterTime is unset.

Read Concern Provenance¶

Starting in version 4.4, MongoDB tracks read concern provenance, which indicates the source of a particular read concern. You may see provenance shown in the getLastError metrics, read concern error objects, and MongoDB logs.

The following table shows the possible read concern provenance values and their significance: