Write Concern写入关注点

On this page本页内容

Write concern describes the level of acknowledgment requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters. 写入关注点描述了MongoDB请求的对独立mongod、副本集或分片集群的写入操作的确认级别。In sharded clusters, mongos instances will pass the write concern on to the shards.在分片集群中，mongos实例将把写关注点传递给分片。

Note

For multi-document transactions, you set the write concern at the transaction level, not at the individual operation level. 对于多文档事务，可以在事务级别而不是单个操作级别设置写关注点。Do not explicitly set the write concern for individual write operations in a transaction.不要为事务中的单个写入操作显式设置写入关注点。

Starting in MongoDB 4.4, replica sets and sharded clusters support setting a global default write concern. 从MongoDB 4.4开始，副本集和分片集群支持设置全局默认写入问题。Operations which do not specify an explicit write concern inherit the global default write concern settings. 未指定显式写入关注点的操作将继承全局默认写入关注点设置。See setDefaultRWConcern for more information.有关更多信息，请参阅setDefaultRWConcern。

Write Concern Specification写关注点规范

Write concern can include the following fields:写关注点可以包括以下字段：

{ w: <value>, j: <boolean>, wtimeout: <number> }

w Option选项

The w option requests acknowledgment that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.w选项请求确认写操作已传播到指定数量的mongod实例或具有指定标记的mongod实例。

Using the w option, the following w: <value> write concerns are available:使用w选项，可以使用以下&w:lt;value>写关注点：

ValueDescription描述
<number>

Requests acknowledgment that the write operation has propagated to the specified number of mongod instances. 请求确认写入操作已传播到指定数量的mongod实例。For example:例如：

w: 1
Requests acknowledgment that the write operation has propagated to the standalone mongod or the primary in a replica set. 请求确认写入操作已传播到副本集中的独立mongod或主mongod。w: 1 is the default write concern for MongoDB. w:1是MongoDB的默认写关注点。Data can be rolled back if the primary steps down before the write operations have replicated to any of the secondaries.如果在写入操作复制到任何辅助设备之前，主设备退出，则可以回滚数据。
w: 0

Requests no acknowledgment of the write operation. 不请求对写入操作的确认。However, w: 0 may return information about socket exceptions and networking errors to the application. 但是，w: 0可能会向应用程序返回有关套接字异常和网络错误的信息。Data can be rolled back if the primary steps down before the write operations have replicated to any of the secondaries.如果在写入操作复制到任何辅助设备之前，主设备退出，则可以回滚数据。

If you specify w: 0 but include j: true, the j: true prevails to request acknowledgment from the standalone mongod or the primary of a replica set.如果指定w: 0但包含j:true，则以j:true为准，从独立mongod或副本集的主mongod请求确认。

w greater than 1 requires acknowledgment from the primary and as many data-bearing secondaries as needed to meet the specified write concern. 大于1的w需要来自主设备和尽可能多的数据承载辅助设备的确认，以满足指定的写入问题。For example, consider a 3-member replica set with a primary and 2 secondaries. 例如，考虑一个带有主元素和2个子元素的3成员副本集。Specifying w: 2 would require acknowledgment from the primary and one of the secondaries. 指定w: 2将需要主服务器和一个辅助服务器的确认。Specifying w: 3 would require acknowledgment from the primary and both secondaries.指定w:3将需要主服务器和两个辅助服务器的确认。

Note

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.隐藏、延迟和优先级为0的成员可以确认w: <number>写入操作。

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.延迟的二级缓存可以在配置的slaveDelay之前返回写确认。

See Acknowledgment Behavior for when mongod instances acknowledge the write.有关mongod实例何时确认写入，请参阅确认行为。

"majority"

Requests acknowledgment that write operations have propagated to the calculated majority of the data-bearing voting members (i.e. primary and secondaries with members[n].votes greater than 0).请求确认写入操作已传播到计算出的大多数数据承载投票成员（即members[n].votes大于0的主要和次要成员）。

For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). 例如，考虑一个具有3个投票成员的副本集，主次二级（P—S—S）。For this replica set, calculated majority is two, and the write must propagate to the primary and one secondary to acknowledge the write concern to the client.对于这个副本集，计算多数是两个，写入必须传播到主副本集和一个辅助副本集，以向客户端确认写入问题。

Note

Hidden, delayed, and priority 0 members with members[n].votes greater than 0 can acknowledge "majority" write operations.隐藏、延迟和优先级为0的成员且members[n].votes大于0的成员可以确认"majority"写入操作。

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.延迟的二级缓存可以在配置的slaveDelay之前返回写确认。

After the write operation returns with a w: "majority" acknowledgment to the client, the client can read the result of that write with a "majority" readConcern.在写操作返回w: "majority"确认给客户机后，客户机可以使用"majority"读取关注点读取该写操作的结果。

See Acknowledgment Behavior for when mongod instances acknowledge the write.有关mongod实例何时确认写入，请参阅确认行为。

<custom write concern name>

Requests acknowledgment that the write operations have propagated to tagged members that satisfy the custom write concern defined in settings.getLastErrorModes. 请求确认写入操作已传播到满足settings.getLastErrorModes中定义的自定义写入问题的tagged（标记）成员。For an example, see Custom Multi-Datacenter Write Concerns.有关示例，请参阅自定义多数据中心写入关注点。

Data can be rolled back if the custom write concern only requires acknowledgement from the primary and the primary steps down before the write operations have replicated to any of the secondaries.如果自定义写操作只需要主设备的确认，并且在将写操作复制到任何辅助设备之前，主设备退出，则可以回滚数据。

See Acknowledgment Behavior for when mongod instances acknowledge the write.有关mongod实例何时确认写入，请参阅确认行为。

See also参阅

j Option选项

The j option requests acknowledgment from MongoDB that the write operation has been written to the on-disk journal.j选项请求MongoDB确认写入操作已写入磁盘日志。

j

If j: true, requests acknowledgment that the mongod instances, as specified in the w: <value>, have written to the on-disk journal. 如果j:true，则请求确认mongod实例（如w:<value>中指定）已写入磁盘日志。j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover.j: true本身并不保证写操作不会由于副本集主故障切换而回滚。

Changed in version 3.2.在版本3.2中更改。With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. 对于j:true，MongoDB只有在请求的成员数（包括主要成员）写入日志后才会返回。Previously j: true write concern in a replica set only requires the primary to write to the journal, regardless of the w: <value> write concern.以前，复制集中的j:true写关注点只要求主服务器写入日志，而不管w:<value>写关注点是什么。

Note

wtimeout

This option specifies a time limit, in milliseconds, for the write concern. 此选项指定写入问题的时间限制（以毫秒为单位）。wtimeout is only applicable for w values greater than 1.仅适用于大于1的w值。

wtimeout causes write operations to return with an error after the specified limit, even if the required write concern will eventually succeed. 导致写入操作在指定限制之后返回错误，即使所需的写入问题最终会成功。When these write operations return, MongoDB does not undo successful data modifications performed before the write concern exceeded the wtimeout time limit.当这些写入操作返回时，MongoDB不会撤消在写入问题超出wtimeout时间限制之前执行的成功数据修改。

If you do not specify the wtimeout option and the level of write concern is unachievable, the write operation will block indefinitely. 如果未指定wtimeout选项且无法实现写入关注级别，则写入操作将无限期阻塞。Specifying a wtimeout value of 0 is equivalent to a write concern without the wtimeout option.将wtimeout值指定为0相当于不带wtimeout选项的写关注点。

Acknowledgment Behavior确认行为

The w option and the j option determine when mongod instances acknowledge write operations.w选项和j选项确定mongod实例何时确认写操作。

Standalone独立的

A standalone mongod acknowledges a write operation either after applying the write in memory or after writing to the on-disk journal. 独立mongod会在将写操作应用到内存中或写入磁盘日志后确认写操作。The following table lists the acknowledgment behavior for a standalone and the relevant write concerns:下表列出了独立服务器的确认行为和相关的写入问题：

 j is unspecified未指明j:truej:false
w: 1 In memory在内存中 On-disk journal在磁盘日志上 In memory在内存中
w: "majority" On-disk journal if running with journaling如果使用日志记录运行，则在磁盘日志上 On-disk journal磁盘日志 In memory在内存中

Note

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. 在writeConcernMajorityJournalDefault设置为false的情况下，MongoDB在确认写操作之前，不会等待w: "majority"写操作写入磁盘日志。As such, majority write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.因此，在给定副本集中的大多数节点出现暂时性丢失（例如崩溃和重新启动）时，majority写入操作可能会回滚。

Replica Sets复制集

The value specified to w determines the number of replica set members that must acknowledge the write before returning success. 指定给w的值确定在返回成功之前必须确认写入的副本集成员的数量。For each eligible replica set member, the j option determines whether the member acknowledges writes after applying the write operation in memory or after writing to the on-disk journal.对于每个符合条件的副本集成员，j选项确定该成员是在内存中应用写操作后确认写操作，还是在写入磁盘日志后确认写操作。

w: "majority"

Any data-bearing voting member of the replica set can contribute to write acknowledgment of "majority" write operations.复制集的任何带有数据的投票成员都可以参与"majority"写入操作的写入确认。

The following table lists when the member can acknowledge the write based on the j value:下表列出了成员可以基于j值确认写入的时间：

j is unspecified未指明

Acknowledgment depends on the value of writeConcernMajorityJournalDefault:确认取决于writeConcernMajorityJournalDefault的值：

  • If true, acknowledgment requires writing operation to on-disk journal (j: true).如果为true，则确认需要将操作写入磁盘日志（j:true）。

    writeConcernMajorityJournalDefault defaults to true默认为true

  • If false, acknowledgment requires writing operation in memory (j: false).如果为false，则确认需要在内存中进行写入操作（j:false）。
j: trueAcknowledgment requires writing operation to on-disk journal.确认需要将操作写入磁盘日志。
j: falseAcknowledgment requires writing operation in memory.确认需要在内存中进行写入操作。

Note

For behavior details, see w: "majority" Behavior.有关行为的详细信息，请参阅w: "majority"行为。

w: <number>

Any data-bearing member of the replica set can contribute to write acknowledgment of w: <number> write operations.复制集的任何数据承载成员都可以参与w:<number>写入操作的写入确认。

The following table lists when the member can acknowledge the write based on the j value:下表列出了成员可以基于j值确认写入的时间：

j is unspecified未指明Acknowledgment requires writing operation in memory (j: false).确认需要在内存中进行写入操作（j:false）。
j: trueAcknowledgment requires writing operation to on-disk journal.确认需要将操作写入磁盘日志。
j: falseAcknowledgment requires writing operation in memory.确认需要在内存中进行写入操作。

Note

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.隐藏、延迟和优先级为0的成员可以确认w:<number>写入操作。

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.延迟的二级缓存可以在配置的slaveDelay之前返回写确认。

Additional Information其他信息

Causally Consistent Sessions and Write Concerns因果一致的会话和写关注点

With causally consistent client sessions, the client sessions only guarantee causal consistency if:对于因果一致的客户端会话，客户端会话仅在以下情况下保证因果一致性：

  • the associated read operations use "majority" read concern, and相关读取操作使用"majority"读取关注点，并且
  • the associated write operations use "majority" write concern.相关的写入操作使用"majority"写入关注点。

For details, see Causal Consistency.有关详细信息，请参阅因果一致性。

w: "majority" Behavior行为

  • With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. 在writeConcernMajorityJournalDefault设置为false的情况下，MongoDB在确认写操作之前，不会等待w: "majority"写操作写入磁盘日志。As such, majority write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.因此，在给定副本集中的大多数节点出现暂时性丢失（例如崩溃和重新启动）时，majority写入操作可能会回滚。
  • Hidden, delayed, and priority 0 members with members[n].votes greater than 0 can acknowledge "majority" write operations.隐藏、延迟和优先级为0且members[n].votes大于0的成员可以确认“多数”写入操作。
    • Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.延迟的二级缓存可以在配置的slaveDelay之前返回写确认。
  • Starting in MongoDB 4.4, replica set members in the STARTUP2 state do not participate in write majorities.从MongoDB 4.4开始，STARTUP2状态下的副本集成员不参与写入多数。

Write Concern not Supported on local Databaselocal数据库不支持写关注点

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

Calculating Majority for Write Concern计算写关注的多数

Tip

Starting in version 4.2.1, the rs.status() returns the writeMajorityCount field which contains the calculated majority number.从版本4.2.1开始，rs.status()返回writeMajorityCount字段，其中包含计算出的多数数。

The majority for write concern "majority" is calculated as the smaller of the following values:写入关注点"majority"的多数计算为以下值中的较小值：

  • the majority of all voting members (including arbiters) vs.所有有表决权的成员（包括仲裁员）的多数对比
  • the number of all data-bearing voting members.所有带有数据的投票成员的数量。

Warning警告

In cases where the calculated majority number is equal to the number of all data-bearing voting members (such as with a 3-member Primary-Secondary-Arbiter deployment), write concern "majority" may time out or never be acknowledged if a data bearing voting member is down or unreachable. 如果计算出的多数数等于所有携带数据的投票成员的数量（例如使用三人主从仲裁员部署），如果携带数据的投票成员失败或无法访问，则"majority"可能会超时或永远不会被确认。If possible, use a data-bearing voting member instead of an arbiter.如果可能的话，使用带有数据的投票成员，而不是仲裁者。

For example, consider:例如，考虑：

  • A replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S):包含3个投票成员的副本集，主要-次要（P-S-S）：

    • The majority of all voting members is 2.所有有表决权的成员的多数是2名。
    • The number of all data-bearing voting members is 3.所有携带数据的投票成员人数为3人。
    The calculated majority is 2, the minimum of 2 and 3. 计算出的多数票是2票，最少是2票和3票。The write must propagate to the primary and one of the secondaries to acknowledge the write concern "majority" to the client.写操作必须传播到主要用户和其中一个辅助用户，以向客户确认写操作的"majority"。
  • A replica set with 3 voting members, Primary-Secondary-Arbiter (P-S-A)一个包含3个投票成员的副本集，主从仲裁员（P-S-A）

    • The majority of all voting members is 2.所有有表决权的成员的多数是2名。
    • The number of all data-bearing voting members is 2.所有携带数据的投票成员人数为2人。
    The calculated majority is 2, the minimum of 2 and 2. Since the write can only be applied to data-bearing members, the write must propagate to the primary and the secondary to acknowledge the write concern "majority" to the client.计算出的多数是2，最小的是2和2。由于写操作只能应用于承载数据的成员，因此写操作必须传播到主成员和次成员，以向客户机确认写操作的"majority"。

    Tip

    Avoid using a "majority" write concern with a (P-S-A) or other topologies that require all data-bearing voting members to be available to acknowledge the writes. 避免在a(P-S-a）或其他拓扑中使用"majority"写入关注点，这些拓扑要求所有具有数据的投票成员都可用于确认写入。Customers who want the durability guarantees of using a "majority" write concern should instead deploy a topology that does not require all data bearing voting members to be available (e.g. P-S-S).希望使用"majority"写入关注点的持久性保证的客户应该部署一种拓扑结构，该拓扑结构不要求所有数据承载投票成员都可用（例如P-S-S）。

Write Concern Provenance写作关注出处

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

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

Provenance发源地Description描述
clientSupplied The write concern was specified in the application.应用程序中指定了写入问题。
customDefault The write concern originated from a custom defined default value. 写入问题源于自定义的默认值。See setDefaultRWConcern.请参阅setDefaultRWConcern。
getLastErrorDefaults The write concern originated from the replica set’s settings.getLastErrorDefaults field.写入问题源自复制集的settings.getLastErrorDefaults字段。
implicitDefault The write concern originated from the server in absence of all other write concern specifications.在没有所有其他写关注规范的情况下，写关注源于服务器。