Docs Home → MongoDB Manual

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. Write concern描述了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.不要为事务中的单个写入操作显式设置写入关注。

If you specify a "majority" write concern for a multi-document transaction and the transaction fails to replicate to the calculated majority of replica set members, then the transaction may not immediately roll back on replica set members. 如果为多文档事务指定了"majority"写入关注，而该事务未能复制到计算出的多数副本集成员，则该事务可能不会立即回滚到副本集成员。The replica set will be eventually consistent. 复制副本集最终将保持一致。A transaction is always applied or rolled back on all replica set members.事务总是在所有复制集成员上应用或回滚。

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> }
  • the w option to request acknowledgment that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.w选项用于请求确认写入操作已传播到指定数量的mongod实例或具有指定标记的mongod实例。
  • the j option to request acknowledgment that the write operation has been written to the on-disk journal, andj选项用于请求确认写入操作已写入磁盘上的日志，以及
  • the wtimeout option to specify a time limit to prevent write operations from blocking indefinitely.wtimeout选项用于指定一个时间限制，以防止写操作无限期阻塞。

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: <value>写入关注：

Value值Description描述
"majority" Requests acknowledgment that write operations have been durably committed 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的primary和secondary）。{ w: "majority" } is the default write concern for most MongoDB deployments. 是大多数MongoDB部署的默认写入关注。See Implicit Default Write Concern.请参阅隐式默认写入关注。
For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). 例如，考虑一个具有3个投票成员的复制集，Primary-Secondary-Secondary（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 secondaryDelaySecs. 延迟的secondary可以在配置的secondaryDelaySecs之前返回写确认。
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"读取关注读取该写入的结果。
If you specify a "majority" write concern for a multi-document transaction and the transaction fails to replicate to the calculated majority of replica set members, then the transaction may not immediately roll back on replica set members. 如果为多文档事务指定了"majority"写入关注，而该事务未能复制到计算的多数副本集成员，则该事务可能不会立即回滚到副本集成员。The replica set will be eventually consistent. 复制副本集最终将保持一致。A transaction is always applied or rolled back on all replica set members.事务总是在所有复制集成员上应用或回滚。
See Acknowledgment Behavior for when mongod instances acknowledge the write. 请参阅确认行为以了解mongod实例何时确认写入。
<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。Data can be rolled back if the primary steps down before the write operations have replicated to any of the secondaries. 如果在写入操作复制到任何辅助设备之前主设备停止运行，则可以回滚数据。
Warning
In MongoDB 4.4 and later, if write operations use { w: 1 } write concern, the rollback directory may exclude writes submitted after an oplog hole if the primary restarts before the write operation completes. 在MongoDB 4.4及更高版本中，如果写入操作使用{ w: 1 }写入关注，则如果主目录在写入操作完成之前重新启动，则回滚目录可能会排除oplog漏洞后提交的写入。
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需要来自主设备的确认，并且需要满足指定写入关注所需的数据承载辅助设备的数量。The secondaries do not need to be voting members to meet the write concern threshold.中学不需要是有投票权的成员就可以达到写入关注的门槛。
For example, consider a 3-member replica set with a primary and 2 secondaries. 例如，考虑一个包含一个主副本和两个辅助副本的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 secondaryDelaySecs. 延迟的secondary可以在配置的secondaryDelaySecs之前返回写确认。
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 acknowledgment 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实例何时确认写入。
Tip

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，则请求确认在w: <value>中指定的mongod实例已写入磁盘上的日志。j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover. 本身并不能保证写入不会由于副本集主故障切换而回滚。
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只有在请求的成员数（包括primary）写入日志后才会返回。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写入关注只需要primary写入日志，而不考虑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选项的写入关注。

Implicit Default Write Concern隐式默认写入关注

Starting in MongoDB 5.0, the implicit default write concern is w: majority. 从MongoDB 5.0开始，隐含的默认写入关注是w: majority。However, special considerations are made for deployments containing arbiters:但是，对于包含仲裁器的部署需要特别注意：

  • The voting majority of a replica set is 1 plus half the number of voting members, rounded down. 复制集的投票多数是1加上投票成员数量的一半，四舍五入。If the number of data-bearing voting members is not greater than the voting majority, the default write concern is { w: 1 }.如果带有数据的投票成员的数量不超过投票多数，则默认的写入关注为{ w: 1 }。
  • In all other scenarios, the default write concern is { w: "majority" }.在所有其他场景中，默认的写入关注是{ w: "majority" }。

Specifically, MongoDB uses the following formula to determine the default write concern:具体来说，MongoDB使用以下公式来确定默认的写入关注：

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

For example, consider the following deployments and their respective default write concerns:例如，考虑以下部署及其各自的默认写入关注：

Non-Arbiters非仲裁器Arbiters仲裁器Voting Nodes投票节点Majority of Voting Nodes大多数投票节点Implicit Default Write Concern隐式默认写入关注
2132{ w: 1 }
4153{ w: "majority" }
  • In the first example:在第一个示例中：

    • There are 2 non-arbiters and 1 arbiter for a total of 3 voting nodes.对于总共3个投票节点，存在2个非仲裁器和1个仲裁器。
    • The majority of voting nodes (1 plus half of 3, rounded down) is 2.大多数投票节点（1加3的一半，四舍五入）为2。
    • The number of non-arbiters (2) is equal to the majority of voting nodes (2), resulting in an implicit write concern of { w: 1 }.非仲裁器的数量（2）等于大多数投票节点（2），导致{ w: 1 }的隐式写入关注。
  • In the second example:在第二个示例中：

    • There are 4 non-arbiters and 1 arbiter for a total of 5 voting nodes.对于总共5个投票节点，有4个非仲裁器和1个仲裁器。
    • The majority of voting nodes (1 plus half of 5, rounded down) is 3.大多数投票节点（1加5的一半，四舍五入）为3。
    • The number of non-arbiters (4) is greater than the majority of voting nodes (3), resulting in an implicit write concern of { w: "majority" }.非仲裁器的数量（4）大于大多数投票节点（3），导致{ w: "majority" }的隐式写入关注。

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: 1In 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
  • 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 secondaryDelaySecs.延迟的secondary可以在配置的secondaryDelaySecs之前返回写确认。

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行为

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.local数据库不支持写入关注。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.所有有投票权的成员（包括仲裁人）的多数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. 在计算出的多数人数等于所有携带数据的投票成员的人数的情况下（例如，部署了3名成员的Primary-Seconary-Arbiter），如果携带数据的表决成员出现故障或无法访问，则写入关注"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个投票成员的复制集，Primary-Secondary-Secondary（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名投票成员组成的复制集，Primary-Secondary-Arbiter（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. 避免在（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）。

Warning

Avoid deploying more than one arbiter in a replica set. See Concerns with Multiple Arbiters.避免在副本集中部署多个仲裁器。请参阅与多个仲裁器有关的问题。

To add an arbiter to an existing replica set:要将仲裁器添加到现有副本集，请执行以下操作：

You do not need to change the cluster wide write concern before starting a new replica set with an arbiter.在使用仲裁器启动新的副本集之前，不需要更改集群范围内的写入关注。

Tip

See also: 另请参阅：

Default write concern formula默认的写入关注公式

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日志中看到出处。

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

Provenance来源Description描述
clientSuppliedThe write concern was specified in the application.写入关注已在应用程序中指定。
customDefaultThe write concern originated from a custom defined default value. 写入关注源自自定义定义的默认值。See setDefaultRWConcern.请参阅setDefaultRWConcern。
getLastErrorDefaultsThe write concern originated from the replica set's settings.getLastErrorDefaults field.写入关注源自复制副本集的settings.getLastErrorDefaults字段。
implicitDefaultThe write concern originated from the server in absence of all other write concern specifications.在没有所有其他写入关注规范的情况下，写入关注源自服务器。

Write Concern Contrasted with Commit Quorum写入关注与提交法定人数对比

There are important differences between commit quorums and write concerns:提交法定人数和写入关注之间存在重要差异：

  • Index builds use commit quorums.索引构建使用提交法定人数。
  • Write operations use write concerns.写操作使用写入关注。

Each data-bearing node in a cluster is a voting member.集群中的每个数据承载节点都是一个投票成员。

The commit quorum specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit a simultaneous index build. before the primary will execute the commit.提交法定人数指定有多少数据承载投票成员，或者必须准备哪些投票成员（包括主要成员）来提交同时索引构建。在主服务器执行提交之前。

The write concern is the level of acknowledgement that the write has propagated to the specified number of instances.写入关注是确认写入已传播到指定数量的实例的级别。

The commit quorum specifies how many nodes must be ready to finish the index build before the primary commits the index build. 提交法定人数指定在主提交索引生成之前，必须准备好多少节点才能完成索引生成。In contrast, when the primary has committed the index build, the write concern specifies how many nodes must finish the index build before the command returns.相反，当主节点提交了索引构建时，写入关注指定在命令返回之前必须有多少节点完成索引构建。