Docs Menu

Write Concern for Replica Sets

On this page

  • Verify Write Operations to Replica Sets
  • Modify Default Write Concern
  • Custom Write Concerns

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.

Write operation to a replica set with write concern level of ``w: "majority"`` or write to the primary and at least one secondary.

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.

The following operation includes the writeConcern option to the insert() method. The operation specifies "majority" write concern and a 5 second timeout using the wtimeout write concern parameter so that the operation does not block indefinitely.

db.products.insert(
{ 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.

Tip
See also:

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.

Tip
See also:

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.

Give Feedback
© 2021 MongoDB, Inc.

About

  • Careers
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2021 MongoDB, Inc.