On this page本页内容
Write concern describes the level of acknowledgment requested from MongoDB for write operations to a standalone 写入关注描述了MongoDB请求的对独立mongod or to replica sets or to sharded clusters. mongod、副本集或分片集群的写入操作的确认级别。In sharded clusters, 在分片集群中，mongos instances will pass the write concern on to the shards.mongos实例将把写问题传递给分片。
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 can include the following fields:写关注点可以包括以下字段：
{ w: <value>, j: <boolean>, wtimeout: <number> }
mongod instances or to mongod instances with specified tags.mongod实例或具有指定标记的mongod实例。wThe 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>写关注点：
| |
| |
|
j OptionThe j option requests acknowledgment from MongoDB that the write operation has been written to the on-disk journal.j选项请求MongoDB确认写入操作已写入磁盘日志。
j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. j: true，MongoDB仅在请求的成员数（包括主成员）写入日志后返回。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>写入关注点无关。
|
j: true to a mongod instance that is running without journaling produces an error.mongod实例指定包含j:true的写关注点会产生错误。w:"majority" may imply j: true. w:"majority"可能意味着j:true。writeConcernMajorityJournalDefault replica set configuration setting determines the behavior. writeConcernMajorityJournalDefault副本集配置设置确定行为。j: true causes an immediate journal synchronization. j:true的写入关注点会立即导致日志同步。wtimeoutThis 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 当这些写入操作返回时，MongoDB不会撤消在写入问题超过wtimeout时间限制之前执行的成功数据修改。wtimeout time limit.
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选项的写关注点。
Starting in MongoDB 5.0, the implicit default write concern is 从MongoDB 5.0开始，隐式默认写入关注点是w: majority. w: majority。However, special considerations are made for deployments containing arbiters:但是，对于包含仲裁器的部署，需要特别考虑：
{ w: 1 }.{ w: 1 }。{ 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:例如，考虑以下部署及其各自的默认写入问题：
| Arbiters | ||||
|---|---|---|---|---|
| 2 | 1 | 3 | 2 | { w: 1 } |
| 4 | 1 | 5 | 3 | { w: "majority" } |
In the first example:在第一示例中：
{ w: 1 }.{w:1}。In the second example:在第二示例中：
{ w: "majority" }.{ w: "majority" }。The w option and the j option determine when w选项和j选项确定mongod instances acknowledge write operations.mongod实例何时确认写入操作。
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 | j:true | j:false | |
|---|---|---|---|
w: 1 | |||
w: "majority" | In memory |
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"写入操作可能会在给定副本集中的大多数节点发生瞬时丢失（如崩溃和重新启动）时回滚。
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 |
|
|---|---|
j: true | |
j: false |
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 | j: false).j:false）。 |
|---|---|
j: true | |
j: false |
Hidden, delayed, and priority 0 members can acknowledge 隐藏、延迟和优先级为0的成员可以确认w: <number> write operations.w: <number>写入操作。
Delayed secondaries can return write acknowledgment no earlier than the configured 延迟的二级设备可以在配置的secondaryDelaySecs.secondaryDelaySecs之前返回写确认。
With causally consistent client sessions, the client sessions only guarantee causal consistency if:对于因果一致的客户端会话，客户端会话仅在以下情况下保证因果一致性：
"majority" read concern, and"majority"读取关注点，以及"majority" write concern."majority"写入关注点。For details, see Causal Consistency.有关详细信息，请参阅因果一致性。
w: "majority"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"写入写入到磁盘日志。"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.members[n].votes大于0的隐藏、延迟和优先级为0的成员可以确认"majority"写入操作。
secondaryDelaySecs.secondaryDelaySecs之前返回写确认。STARTUP2 state do not participate in write majorities.STARTUP2状态下的副本集成员不参与写入多数。local Databaselocal数据库不支持写问题The local database does not support write concerns. local数据库不支持写关注点。MongoDB silently ignores any configured write concern for an operation on a collection in the local database.MongoDB静默地忽略本地数据库中集合上的操作的任何已配置写入关注点。
Starting in version 4.2.1, the 从版本4.2.1开始，rs.status() returns the writeMajorityCount field which contains the calculated majority number.rs.status()返回writeMajorityCount字段，其中包含计算出的多数数。
The majority for write concern 写入关注点"majority" is calculated as the smaller of the following values:"majority"的多数计算为以下值中的较小值：
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）：
"majority" to the client."majority"。A replica set with 3 voting members, Primary-Secondary-Arbiter (P-S-A)具有3个投票成员的副本集，主-次仲裁器（P-S-A）
"majority" to the client."majority"。Avoid using a 避免在a(P-S-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. "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）。
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.在使用仲裁器启动新的副本集之前，无需更改集群范围的写关注点。
Starting in version 4.4, MongoDB tracks write concern 从版本4.4开始，MongoDB跟踪写关注点的provenance, which indicates the source of a particular write concern. 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值及其重要性：
clientSupplied | |
customDefault | setDefaultRWConcern.setDefaultRWConcern。
|
getLastErrorDefaults | settings.getLastErrorDefaults field.settings.getLastErrorDefaults字段。
|
implicitDefault |