Navigation
This version of the documentation is archived and no longer supported.

Write Concern Reference

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 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> }

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.

The w option accepts the following values:

Value Description
<number>

Requests acknowledgement that the write operation has propagated to the specified number of mongod instances. For example:

w: 1
Requests acknowledgement that the write operation has propagated to the standalone mongod or the primary in a replica set. w: 1 is the default write concern for MongoDB.
w: 0

Requests no acknowledgment of the write operation. However, w: 0 may return information about socket exceptions and networking errors to the application.

If you specify w: 0 but include j: true, the j: true prevails to request acknowledgement from the standalone mongod or the primary of a replica set.

Numbers greater than 1 are valid only for replica sets to request acknowledgement from specified number of members, including the primary. If you set w to a number that is greater than the number of set members that hold data, MongoDB waits for the non-existent members to become available, which means MongoDB blocks indefinitely.

"majority"

Requests acknowledgment that write operations have propagated to the majority of voting nodes.

Changed in version 3.0: In previous versions, 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.

<tag set>
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.

j
Requests acknowledgement from MongoDB that the write operation has been written to the journal. j: true by itself does not guarantee that the write will not be rolled back due to replica set primary failover.

Changed in version 2.6: Specifying a write concern that includes j: true to a mongod or mongos running with --nojournal option now errors. Previous versions would ignore the j: true.

Note

Requiring journaled write concern in a replica set only requires a journal commit of the write operation to the primary of the set regardless of the w: <value> write concern.

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.