Read Concern

在本页面

readConcern选项使您可以控制从副本集和副本集分片读取的数据的近期性,一致性和隔离性。

通过有效使用write concerns和阅读关注事项,您可以适当地调整一致性和可用性保证的级别,例如 await 更强的一致性保证,或者放宽一致性要求以提供更高的可用性。

为 MongoDB 3.2 或更高版本更新的 MongoDB 驱动程序支持指定读取关注。

阅读关注级别

提供以下阅读关注级别:

levelDescription
"local"该查询从实例返回数据,但不能保证该数据已被写入大多数副本集成员(即可以回滚)。


Default for:
反对主要
如果读取与因果一致的会话关联,则针对次要读取。
阅读关注local可用于因果一致的会话。
有关更多信息,请参见"local"参考页。
| "available" |查询从实例返回数据,但不保证该数据已被写入大多数副本集成员(即可以回滚)。
如果读取与因果一致的会话没有关联,则针对次要读取的默认设置。
对于分片集合,"available"读取关注点提供了各种读取关注点中可能的最低延迟读取,但是由于"available"读取关注点可以返回孤立文档,因此牺牲了一致性。
阅读关注available无法用于因果一致的会话。
有关更多信息,请参见"available"参考页。
3.6 版中的新功能。
| "majority" |查询将返回大多数副本集成员已确认的数据。读取操作返回的文档即使在发生故障的情况下也很持久。
要使用read concern级别"majority",副本集必须使用WiredTiger 存储引擎和选举协议版本 1
从 MongoDB 3.6 开始,默认情况下启用对读取关注"majority"的支持。对于 MongoDB 3.6.1-3.6.x,您可以禁用阅读关注"majority"。有关更多信息,请参见禁用多数阅读关注
阅读关注majority可用于因果一致的会话。
有关更多信息,请参见"majority"参考页。
| "linearizable" |查询返回的数据反映了在读取操作开始之前完成的所有成功的多数确认写入。在返回结果之前,查询可以 await 并发执行的写入传播到大多数副本集成员。
如果大多数副本集成员崩溃并在读取操作后重新启动,则如果将writeConcernMajorityJournalDefault设置为默认状态true,则由读取操作返回的文档将是持久的。
writeConcernMajorityJournalDefault设置为false的情况下,MongoDB 在确认写入之前不会 awaitw: "majority"写入磁盘日志上。这样,如果给定副本集中的大多数节点发生瞬时丢失(例如崩溃和重新启动),则majority写操作可能会回滚。
您只能为primary上的读取操作指定线性化读取关注。
阅读关注linearizable无法用于因果一致的会话。
可线性化的读取关注保证仅在读取操作指定唯一标识单个文档的查询过滤器时适用。

Tip





万一大多数数据承载成员不可用,请始终将maxTimeMS与可线性化的读取注意事项一起使用。 maxTimeMS确保该操作不会无限期地阻塞,而是确保如果无法满足读取要求,则该操作将返回错误。



有关更多信息,请参见"linearizable"参考页。

无论read concern级别如何,节点上的最新数据都可能无法反映系统中数据的最新版本。

有关每个阅读关注级别的更多信息,请参见:

readConcern Syntax

您可以指定readConcern级别[1]作为选项:

readConcern: { level: <"majority"|"local"|"linearizable"|"available"> }

因果一致的会话和可用的阅读问题

对于因果一致的会话"local""majority"级别的操作可用。但是,为了保证因果一致性,必须使用"majority"。有关详细信息,请参见Causal Consistency

支持阅读关注的操作

以下操作支持readConcern选项:

要为mongo shell 方法db.collection.find()指定读取关注级别,请使用cursor.readConcern()方法:

db.collection.find().readConcern(<"majority"|"local"|"linearizable"|"available">)
[1]对于因果一致的会话,MongoDB 驱动程序会在读取关注中自动指定afterClusterTime值。

Considerations

阅读您自己的文章

在版本 3.6 中更改。

从 MongoDB 3.6 开始,如果写入请求确认,则可以使用因果一致的会话来读取自己的写入。

在 MongoDB 3.6 之前,您必须以{ w: "majority" }写入关注度发出写入操作,然后对读取操作使用"majority""linearizable"读取关注度,以确保单个线程可以读取自己的写入。

实时订单

结合"majority"写入关注点和"linearizable"读取关注点,可使多个线程对单个文档执行读写操作,就好像单个线程实时执行了这些操作一样;也就是说,这些读写的相应计划被认为是线性的。

Performance Comparisons

"majority"不同,"linearizable"读关注与辅助成员确认读操作正在从主要对象读取,该操作能够以{ w: "majority" }写关注来确认写。 [2]这样,具有线性化读取关注点的读取可能比具有"majority""local"读取关注点的读取慢得多。

万一大多数数据承载成员不可用,请始终将maxTimeMS与可线性化的读取注意事项一起使用。 maxTimeMS确保该操作不会无限期地阻塞,而是确保如果无法满足读取要求,则该操作将返回错误。

For example:

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

db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )
[2]some circumstances中,副本集中的两个节点可能暂时认为它们是主要节点,但是最多,其中一个节点将能够完成{ w: "majority" }写入关注。可以完成{ w: "majority" }写操作的节点是当前主节点,另一个节点是以前的主节点,通常由于network partition而尚未识别其降级。发生这种情况时,尽管已请求读取首选项primary,但连接到先前主服务器的 Client 端仍可能会观察到过时的数据,并且对先前主服务器的新写入最终将回滚。

读取操作和因果一致的会话

3.6 版的新功能。

MongoDB 3.6 引入了对因果一致的会话的支持。对于与因果一致的会话相关联的读取操作,MongoDB 3.6 引入了afterClusterTime读取关注选项,驱动程序会自动为与因果一致的会话相关联的操作设置afterClusterTime读取关注选项。

afterClusterTime读关注级别选项可用于"local""majority"读关注级别:

Important

不要手动设置afterClusterTime。 MongoDB 驱动程序会针对与因果一致的会话相关联的操作自动设置此值。

readConcern: { level: <"majority"|"local"> , afterClusterTime: <Timestamp> }

为了满足afterClusterTime值为T的读取请求,mongod必须在其 oplog 到达时间T之后执行请求。如果其操作日志尚未达到时间T,则mongod必须 await 为该请求提供服务。

使用指定的afterClusterTime的读取操作将返回同时满足阅读关注度要求和指定的afterClusterTime要求的数据。

对于与因果关系一致的会话无关的读取操作,未设置afterClusterTime