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 default write concern of w: 1 requires 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.

Write operations with a write concern of "majority" require acknowledgement that the write operations have propagated to a calculated majority of the data-bearing voting members. For clusters where members have journaling enabled, combining "majority" write concern with j : true can prevent rollback of write concern acknowledged data.

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.

Verify Write Operations to Replica Sets¶

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.

copy

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.

Modify Default Write Concern¶

You can modify the default write concern for a replica set by setting the settings.getLastErrorDefaults setting in the replica set configuration. The following sequence of commands creates a configuration that waits for the write operation to complete on a majority of the voting members before returning:

copy

cfg = rs.conf()
cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
rs.reconfig(cfg)

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.

← Replica Set Read and Write Semantics Read Preference →