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. However, to guarantee causal consistency, you must use "majority". 对于因果一致会话中的操作，可以使用"local"、"majority"和"snapshot"级别。但是，为了保证因果关系的一致性，必须使用"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值及其重要性：