Write Concern for Replica Sets
On this page
Write concern for replica sets describe the number of data-bearing members (i.e. the primary and secondaries, but not arbiters) that must acknowledge a write operation before the operation returns as successful. A member can only acknowledge a write operation after it has received and applied the write successfully.
For replica sets, the write concern of
w: "majority" requires acknowledgement that
the write operations have propagated to a
calculated majority of the
data-bearing voting members. For most replica set configurations,
w: "majority" is the default
write concern. To learn how MongoDB determines the default write
concern, see Implicit Default Write Concern.
For clusters where members have journaling
enabled, combining "majority" write concern with j :
true can prevent rollback of write
concern acknowledged data.
Write operations with a write concern of
w: 1 require that only the primary replica
set member acknowledge the write before returning write concern
acknowledgment. You can specify an integer value greater than 1 to
require acknowledgment from the primary and as many secondaries as
needed to meet the specified value, up to the total number of
data-bearing members in the replica set.
For complete documentation on write acknowledgment behavior, see Acknowledgment Behavior.
An application that issues a write operation that requires
write concern acknowledgment waits until the primary receives
acknowledgment from the required number of members for the specified
write concern. For write concern of w greater than 1 or
w : "majority", the primary waits until the required number of
secondaries acknowledge the write before returning write concern
acknowledgment. For write concern of w: 1, the primary can return
write concern acknowledgment as soon as it locally applies the write
since it is eligible for contributing to the requested write concern.
The more members that acknowledge a write, the less likely the written data could roll back if the primary fails. However, specifying a high write concern can increase latency as the client must wait until it receives the requested level of write concern acknowledgment.
Selecting the ideal write concern for any given write operation depends on your application's performance goals and data durability requirements. For more guidance on configuring write concern to prevent rollbacks, see Avoid Replica Set Rollbacks.
Verify Write Operations to Replica Sets
The following operation includes the writeConcern option for
the insertOne() method. The operation
specifies:
- the "majority" write concern, and
- a 5 second timeout.
The wtimeout write concern parameter ensures that the
operation does not block indefinitely.
db.products.insertOne( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: "majority" , wtimeout: 5000 } } )
The application waits until the primary returns write concern
acknowledgment, indicating that a calculated majority of the data-bearing voting members
acknowledged the write operation. For example, in a 3-member
replica set (P-S-S), the operation would require acknowledgment from 2 out of
the 3 members. If the replica set was later scaled to include two
additional voting secondary members, the same operation would require
acknowledgment from 3 out of the 5 replica set members. If the
primary does not return write concern acknowledgment within the
wtimeout limit, the write operation fails with a write concern
error.
A write operation that times out waiting for the specified write concern
only indicates that the required number of replica set members did not
acknowledge the write operation within the wtimeout time period.
It does not necessarily indicate that the primary failed to apply the
write. The data may exist on a subset of replica set nodes at the time
of the write concern error, and can continue replicating until all
nodes in the cluster have that data. Applications should take into
account the potential availability of written data regardless of the
state of write concern acknowledgment.
The exact syntax for specifying write concern depends on the write operation. Refer to the documentation for the write operation for instructions on write concern support and syntax. For complete documentation on write concern, see Write Concern.
Modify Default Write Concern
You can modify the default write concern for a replica set by issuing
the setDefaultRWConcern command.
If you issue a write operation with a specific write concern, the write operation uses its own write concern instead of the default.
Custom Write Concerns
You can tag the members of replica sets and use the resulting tag sets to create custom write concerns. See Configure Replica Set Tag Sets for information on configuring custom write concerns using tag sets.