- MongoDB CRUD Operations >
- MongoDB CRUD Reference >
- Write Concern Reference
Write Concern Reference¶
On this page
Write concern describes the guarantee that MongoDB provides when reporting on the success of a write operation.
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.
Available Write Concern¶
Write concern can include the w option to specify the required number of acknowledgments before returning, the j option to require writes to the journal before returning, and wtimeout option to specify a time limit to prevent write operations from blocking indefinitely.
In sharded clusters, mongos
instances will pass the write
concern on to the shard.
w
Option¶
The w
option provides the ability to disable write concern entirely
as well as specify the write concern for replica sets.
MongoDB uses w: 1
as the default write concern. w: 1
provides basic receipt acknowledgment.
The w
option accepts the following values:
Value | Description |
---|---|
1 |
Provides acknowledgment of write operations on a standalone
This is the default write concern for MongoDB. |
0 |
Disables basic acknowledgment of write operations, but returns information about socket exceptions and networking errors to the application. If you disable basic write operation acknowledgment but require
journal commit acknowledgment, the journal commit prevails, and
the server will require that |
<Number greater than 1> | Guarantees that write operations have propagated successfully to the specified number of replica set members including the primary. For example, If you set |
"majority" |
Confirms that write operations have propagated to the majority of configured replica set: a majority of the set’s configured members must acknowledge the write operation before it succeeds. This allows you to avoid hard coding assumptions about the size of your replica set into your application. Changed in version 2.6: In Master/Slave deployments,
MongoDB treats |
<tag set> | By specifying a tag set, you can have fine-grained control over which replica set members must acknowledge a write operation to satisfy the required level of write concern. |
j
Option¶
The j
option confirms that the mongod
instance has
written the data to the on-disk journal. This ensures that data is not
lost if the mongod
instance shuts down unexpectedly. Set to
true
to enable.
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 level of replica acknowledged 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.
See also
Write Concern Introduction and Write Concern for Replica Sets.