- MongoDB CRUD Operations >
- MongoDB CRUD Reference >
- 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.
Changed in version 3.2: For replica sets using protocolVersion: 1 and running with the journal enabled:
- w: "majority" implies j: true.
- Secondary members acknowledge replicated write operations after the secondary members have written to their respective on-disk journals, regardless of the j option used for the write on the primary.
Changed in version 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
- 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:
Note
Standalone mongod instances and primaries of replica sets acknowledge write operations after applying the write in memory, unless j:true.
Changed in version 3.2: For replica sets using protocolVersion: 1, secondaries acknowledge write operations after the secondary members have written to their respective on-disk journals, regardless of the j option.
| 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. |
|
Changed in version 3.2 Requests acknowledgment that write operations have propagated to the majority of voting nodes [1], including the primary, and have been written to the on-disk journal for these nodes. For replica sets using protocolVersion: 1, w: "majority" implies j: true. So, unlike w: <number>, with w: "majority", the primary also writes to the on-disk journal before acknowledging the write. 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. |
|
Requests acknowledgement that the write operations have propagated to a replica set member with the specified tag. |
j Option¶
The j option requests acknowledgement from MongoDB that the write operation has been written to the journal.
|
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. Changed in version 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. For replica sets using protocolVersion: 1, w: "majority" implies j: true, if journaling is enabled. Journaling is enabled by default. |
Changed in version 2.6: Specifying a write concern that includes j: true to a mongod or mongos running with --nojournal option produces an error. Previous versions would ignore the j: true.
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.
| [1] | Changed in version 3.0: Prior to MongoDB 3.0, w: "majority" refers to the majority of the replica set’s members. Changed in version 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. |