- MongoDB CRUD 操作 >
- Write Concern
Write Concern¶
On this page
Write concern describes the level of acknowledgement requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters. In sharded clusters, mongos instances will pass the write concern on to the shards.
在 2.6 版更改: A new protocol for write operations integrates write concerns with the write operations and eliminates the need to call the getLastError command. Previous versions required a getLastError command immediately after a write operation to specify the write concern.
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.
- the j option to request acknowledgement that the write operation has been written to the journal, and
- the wtimeout option to specify a time limit to prevent write operations from blocking indefinitely.
w Option¶
The w option requests acknowledgement that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.
Using the w option, the following w: <value> write concerns are available:
| Value | Description |
|---|---|
|
Requests acknowledgement that the write operation has propagated to the specified number of mongod instances. For example:
Numbers greater than 1 are valid only for replica sets to request acknowledgement from specified number of members, including the primary. See Acknowledgement Behavior for when mongod instances acknowledge the write. |
|
Requests acknowledgment that write operations have propagated to the majority of voting nodes [2], including the primary. After the write operation returns with a w: "majority" acknowledgement to the client, the client can read the result of that write with a "majority" readConcern. See Acknowledgement Behavior for when mongod instances acknowledge the write. |
|
Requests acknowledgement that the write operations have propagated to a replica set member with the specified tag. See Acknowledgement Behavior for when mongod instances acknowledge the write. |
j Option¶
The j option requests acknowledgement from MongoDB that the write operation has been written to the journal.
|
If j: true, requests acknowledgement that the mongod instances, as specified in the w: <value>, have written to the on-disk journal. j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover. 在 3.2 版更改: With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. 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. |
注解
- Specifying a write concern that includes j: true to a mongod instance that is running without journaling produces an error.
- For replica sets using protocolVersion: 1, if journaling is enabled, w: "majority" may imply j: true. The writeConcernMajorityJournalDefault replica set configuration setting determines the behavior. See Acknowledgement Behavior for details.
wtimeout¶
This option specifies a time limit, in milliseconds, for the write concern. wtimeout is only applicable for w values greater than 1.
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.
If you do not specify the wtimeout option and the level of write concern is unachievable, the write operation will block indefinitely. Specifying a wtimeout value of 0 is equivalent to a write concern without the wtimeout option.
Acknowledgement Behavior¶
The w option and the j option determine when mongod instances acknowledge write operations.
Standalone¶
A standalone mongod acknowledges a write operation either after applying the write in memory or after writing to the on-disk journal. The following table lists the acknowledgement behavior for a standalone and the relevant write concerns:
| j is unspecified | j:true | j:false | |
|---|---|---|---|
| w: 1 | In memory | On-disk journal | In memory |
| w: "majority" | On-disk journal if running with journaling | On-disk journal | In memory |
注解
With writeConcernMajorityJournalDefault set to false, MongoDB will not wait for w: "majority" writes to be durable before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a loss of a replica set member.
Replica Sets¶
在 3.4 版更改.
A replica set acknowledges a write operation either after the specified number of members apply the write in memory or after they write to the on-disk journal. The number of members is specified by the w: <value> setting. The following table lists the acknowledgement behavior for these members and the relevant write concerns [1]:
| j is unspecified | j:true | j:false | |
|---|---|---|---|
| w: "majority" | Depends on the value of writeConcernMajorityJournalDefault.
在 3.4 版更改. |
On-disk journal | In memory |
| w: <number> | In memory | On-disk journal | In memory |
注解
With writeConcernMajorityJournalDefault set to false, MongoDB will not wait for w: "majority" writes to be durable before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a loss of a replica set member.
| [1] | For the behavior in version 3.2, refer to the 3.2 manual. |
| [2] | 在 3.0 版更改: Prior to MongoDB 3.0, w: "majority" refers to the majority of the replica set’s members instead of the majority of the replica set’s voting members. 在 2.6 版更改: In Master/Slave deployments, MongoDB treats w: "majority" as equivalent to w: 1. In earlier versions of MongoDB, w: "majority" produces an error in master/slave deployments. |