Write Concern for Replica Sets

Write concern for replica sets describe thenumber of data-bearing members (i.e. the primary and secondaries,but not arbiters) that must acknowledge a write operation before theoperation returns as successful. A member can only acknowledge awrite operation after it has received and applied the writesuccessfully.

For replica sets, the default write concern ofw: 1 requires that only the primaryreplica set member acknowledge the write before returningwrite concern acknowledgment. You can specify an integervalue greater than 1 to require acknowledgment from the primary andas many secondaries as needed to meet the specified value, up to thetotal 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 tothe majority (M) of data-bearing voting members. The majority(M) is calculated as a simple majority of all voting members, but thewrite operation returns acknowledgement after propagating to M-numberof data-bearing voting members (primary and secondaries withmembers[n].votes greater than 0). Forclusters where members have journalingenabled, combining "majority" write concern withj : true can preventrollback of write concern acknowledgeddata.

For complete documentation on write acknowledgmentbehavior, 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 requireswrite concern acknowledgment waits until the primary receivesacknowledgment from the required number of members for the specifiedwrite concern. For write concern of w greater than 1 orw : "majority", the primary waits until the required number ofsecondaries acknowledge the write before returning write concernacknowledgment. For write concern of w: 1, the primary can returnwrite concern acknowledgment as soon as it locally applies the writesince it is eligible for contributing to the requested write concern.

The more members that acknowledge a write, the less likely the writtendata could roll back if theprimary fails. However, specifyinga high write concern can increase latency as the client must wait untilit receives the requested level of write concern acknowledgment.

Selecting the ideal write concern for any given write operation dependson your application’s performance goals and data durabilityrequirements. For more guidance on configuring write concern toprevent rollbacks, see Avoid Replica Set Rollbacks.

Verify Write Operations to Replica Sets

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

  1. db.products.insert(
  2.    { item: "envelopes", qty : 100, type: "Clasp" },
  3.    { writeConcern: { w: "majority" , wtimeout: 5000 } }
  4. )

The application waits until the primary returns write concernacknowledgment, indicating that a simple majority (M) ofdata-bearing voting members acknowledged the write operation. Themajority (M) is calculated as the majority of all voting members,and not just the data-bearing voting members. For example, in a 3-memberreplica set the operation would require acknowledgment from 2 out ofthe 3 members. If the replica set was later scaled to include twoadditional voting nodes, the same operation would requireacknowledgment from 3 out of the 5 replica set members. If theprimary does not return write concern acknowledgment within thewtimeout limit, the write operation fails with a write concernerror.

A write operation that times out waiting for the specified write concernonly indicates that the required number of replica set members did notacknowledge the write operation within the wtimeout time period.It does not necessarily indicate that the primary failed to apply thewrite. The data may exist on a subset of replica set nodes at the timeof the write concern error, and can continue replicating until allnodes in the cluster have that data. Applications should take intoaccount the potential availability of written data regardless of thestate of write concern acknowledgment.

The exact syntax for specifying write concern depends on the writeoperation. Refer to the documentation for the write operation forinstructions on write concern support and syntax. For completedocumentation on write concern, see Write Concern.

See also

Write Method Acknowledgements

Modify Default Write Concern

You can modify the default write concern for a replica set by settingthe settings.getLastErrorDefaults settingin the replica set configuration. The following sequence of commandscreates a configuration that waits for the write operation to completeon a majority of the voting members before returning:

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

If you issue a write operation with a specific write concern, the writeoperation uses its own write concern instead of the default.

See also

Write Concern

Custom Write Concerns

You can tag themembers of replica sets and use the resulting tag sets to create custom writeconcerns. See Configure Replica Set Tag Sets forinformation on configuring custom write concerns using tag sets.