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级别作为支持读取关注的命令和方法的选项：

readConcern: { level: <level> }

To specify the read concern level for mongosh method db.collection.find(), use the cursor.readConcern() method:要为mongosh方法db.collection.find()指定读取关注级别，请使用cursor.readConcern()方法：

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, you can create collections and indexes inside a transaction. 从MongoDB 4.4开始，您可以在事务中创建集合和索引。If explicitly creating a collection or an index, the transaction must use read concern "local". 如果显式创建集合或索引，则事务必须使用"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", "majority", and "snapshot" levels are available. 对于因果一致会话中的操作，可以使用"local"、"majority"和"snapshot"级别。However, to guarantee causal consistency, you must use "majority". 然而，为了保证因果一致性，必须使用"majority"。For details, see Causal Consistency.有关详细信息，请参阅因果一致性。

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 Databaselocal数据库不支持读取关注

The local database does not support read concerns. local数据库不支持读取问题。MongoDB silently ignores any configured read concern for an operation on a collection in the local database.MongoDB会自动忽略本地数据库中集合操作的任何已配置读取问题。

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.从MongoDB 3.6开始，如果写入请求确认，您可以使用因果一致的会话来读取自己的写入。

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.在MongoDB 3.6之前，为了读取您自己的写入操作，您必须使用{ w: "majority" }写入关注点来执行写入操作，然后使用primary读取首选项以及"majority"或"linearizable"读取关注点来执行读取操作。

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.与"majority"写关注点相结合，"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. 与"majority"不同，"linearizable"读关注点向次要成员确认读操作是从能够确认具有{ w: "majority" }写关注点的写操作的主要成员读取。[4] As such, reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns.因此，具有线性化读取关注点的读取可能比具有"majority"或"local"读取关注点的读取慢得多。

Always use maxTimeMS with linearizable read concern in case a majority of data bearing members are unavailable. 在大多数数据承载成员不可用的情况下，始终使用具有线性化读取问题的maxTimeMS。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.maxTimeMS确保操作不会无限期阻塞，而是确保在无法满足读取问题时，操作返回错误。

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. MongoDB 3.6引入了对因果一致会话的支持。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.对于与因果一致性会话相关的读取操作，MongoDB 3.6引入了afterClusterTime读取关注选项，由驱动程序为与因果一致性会话相关的操作自动设置。

To satisfy a read request with an afterClusterTime value of T, a mongod must perform the request after its oplog reaches time T. 要满足afterClusterTime值为T的读取请求，mongod必须在其oplog达到时间T后执行该请求。If its oplog has not reached time T, the mongod must wait to service the request.如果其oplog尚未达到时间T，mongod必须等待服务请求。

Read operations with a specified afterClusterTime return data that meet both the read concern level requirement and the specified afterClusterTime requirement.具有指定afterClusterTime的读取操作将返回同时满足读取关注级别要求和指定afterClusterTime要求的数据。

For read operations not associated with causally consistent sessions, afterClusterTime is unset.对于与因果一致会话无关的读取操作，afterClusterTime未设置。

Read Concern Provenance阅读关注出处

Starting in version 4.4, MongoDB tracks read concern provenance, which indicates the source of a particular read concern. 从版本4.4开始，MongoDB跟踪读取关注点的provenance，它指示特定读取关注点的来源。You may see provenance shown in the getLastError metrics, read concern error objects, and MongoDB logs.您可能会在getLastError度量、读取关注错误对象和MongoDB日志中看到provenance。

The following table shows the possible read concern provenance values and their significance:下表显示了可能的读数provenance值及其重要性：