mongodb "Write Concern"

Write Concern

On this page
Write
Concern Specification
Acknowledgement
Behavior

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

the w option to request acknowledgement 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
<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 acknowledgement 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. See Acknowledgement Behavior for when  mongod  instances acknowledge the write.
"majority"	Requests acknowledgement 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.
<tag set>	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.

SEE ALSO
Replica Set Protocol Versions

j

 Option

The 

j

 option requests acknowledgement from MongoDB that the write operation has been written to thejournal.

j

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

NOTE
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

NOTE
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

Changed in version 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 . If true, On-disk journal. If false, In memory. Changed in version 3.4.	On-disk journal	In memory
w: <number>	In memory	On-disk journal	In memory

NOTE
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]

Changed in version 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. 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.

原文网址：https://docs.mongodb.com/manual/reference/write-concern/