Docs HomeMongoDB Manual

Read Concern 读取关注"majority"

"majority"

For read operations not associated with multi-document transactions, read concern "majority" guarantees that the data read has been acknowledged by a majority of the replica set members (i.e. the documents read are durable and guaranteed not to roll back).对于与多文档事务无关的读取操作,读取关系"majority"保证读取的数据已得到大多数副本集成员的确认(即,读取的文档是持久的,并保证不会回滚)。

For operations in multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern "majority". 对于多文档事务中的操作,只有当事务以写入关注"majority"提交时,读取关注"majority"才提供其保证。Otherwise, the "majority" read concern provides no guarantees about the data read in transactions.否则,"majority"读取关注无法保证事务中读取的数据。

Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.无论读取关注级别如何,节点上的最新数据都可能无法反映系统中数据的最新版本。

Performance性能

Each replica set member maintains, in memory, a view of the data at the majority-commit point; the majority-commit point is calculated by the primary. 每个副本集成员在内存中维护多数提交点的数据视图;多数提交点由主要提交点计算。To fulfill read concern "majority", the node returns data from this view and is comparable in performance cost to other read concerns.为了实现读取关注"majority",节点从该视图返回数据,并且在性能成本上与其他读取关注相当。

Availability可用性

Read concern "majority" is available for use with or without causally consistent sessions and transactions.读取关注"majority"可在具有或不具有因果一致会话和事务的情况下使用。

Warning

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:如果您使用的是由三个成员组成的主辅仲裁器(PSA)架构,请考虑以下事项:

  • The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. 如果辅助设备不可用或滞后,写入关注"majority"可能会导致性能问题。For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.有关如何缓解这些问题的建议,请参阅使用PSA副本集缓解性能问题
  • If you are using a global default "majority" and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.如果使用全局默认的"majority",并且写入关注小于多数的大小,则查询可能会返回过时(未完全复制)的数据。

Example实例

Consider the following timeline of a write operation Write 0 to a three member replica set:请考虑以下写入操作的时间线将0写入三成员副本集:

Note

For simplification, the example assumes:为了简化,该示例假设:

  • All writes prior to Write 0 have been successfully replicated to all members.写入0之前的所有写入操作都已成功复制到所有成员。
  • Write prev is the previous write before Write 0.写入prev是写入0之前的上一次写入。
  • No other writes have occured after Write 0.写入0之后没有发生其他写入操作。
Timeline of a write operation to a three member replica set.
TimeEventMost Recent WriteMost Recent w: "majority" write
t 0Primary applies Write 0Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 1Secondary 1 applies write 0Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 2Secondary 2 applies write 0Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 3Primary is aware of successful replication to Secondary 1 and sends acknowledgement to client主服务器知道已成功复制到辅助服务器1,并向客户端发送确认Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t 4Primary is aware of successful replication to Secondary 2主服务器知道已成功复制到辅助服务器2Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t 5Secondary 1 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write辅助1收到通知(通过常规复制机制)更新其最近w:“多数”写入的快照Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
t 6Secondary 2 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write辅助2收到通知(通过常规复制机制)更新其最近w:“多数”写入的快照Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0

Then, the following tables summarizes the state of the data that a read operation with "majority" read concern would see at time T.然后,下表总结了具有"majority"读取关注的读取操作在时间T时会看到的数据状态。

Timeline of a write operation to a three member replica set.
Read Target读取目标Time 时间TState of Data数据状态
PrimaryBefore t 3Data reflects Write prev数据反映写入prev
PrimaryAfter t 3Data reflects Write 0
Secondary 1Before t 5Data reflects Write prev
Secondary 1After t 5Data reflects Write 0
Secondary 2Before or at t 6Data reflects Write prev
Secondary 2After t 6Data reflects Write 0

Storage Engine Support存储引擎支持

Read concern "majority" is available for the WiredTiger storage engine.WiredTiger存储引擎可使用"majority"读取关注。

Tip

The serverStatus command returns the storageEngine.supportsCommittedReads field which indicates whether the storage engine supports "majority" read concern.serverStatus命令返回storageEngine.supportsCommittedReads字段,该字段指示存储引擎是否支持"majority"读取关注。

Read Concern "majority" and Transactions读取关注"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.要设置事务的读取关注,请参阅事务和读取关注

For operations in multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern "majority". 对于多文档事务中的操作,只有当事务以写关注“多数”提交时,读关注"majority"才提供其保证。Otherwise, the "majority" read concern provides no guarantees about the data read in transactions.否则,"majority"读取关注无法保证事务中读取的数据。

Read Concern "majority" and Aggregation读取关注"majority"和聚合

Starting in MongoDB 4.2, you can specify read concern level "majority" for an aggregation that includes an $out stage.从MongoDB 4.2开始,您可以为包含$out阶段的聚合指定读取关注级别read concern level "majority"

Read Your Own Writes阅读自己的文章

Changed in version 3.6.3.6版更改。

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"读取关注。

Primary-Secondary-Arbiter Replica Sets主辅助仲裁器副本集

Starting in MongoDB 5.0, enableMajorityReadConcern and --enableMajorityReadConcern cannot be changed and are always set to true due to storage engine improvements.从MongoDB 5.0开始,由于存储引擎的改进,enableMajorityReadConcern--enableMajorityReadConcern不能更改,并且始终设置为true

In earlier versions of MongoDB, enableMajorityReadConcern and --enableMajorityReadConcern are configurable and can be set to false to prevent storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture.在MongoDB的早期版本中,enableMajorityReadConcern--enableMajorityReadConcern是可配置的,并且可以设置为false,以防止存储缓存压力固定具有三成员主-辅助仲裁器(PSA)架构的部署。

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:如果您使用的是由三个成员组成的主辅仲裁器(PSA)架构,请考虑以下事项:

  • The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. 如果辅助设备不可用或滞后,写入关注"majority"可能会导致性能问题。For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.有关如何缓解这些问题的建议,请参阅使用PSA副本集缓解性能问题
  • If you are using a global default "majority" and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.如果使用全局默认的"majority",并且写入关注小于多数的大小,则查询可能会返回过时(未完全复制)的数据。