What is the default mongod write concern in which version?

Question

I could not find in mongodb\'s documentation what\'s the default write concern and how an \"acknowledged write\" is defined. It seems that this have changed throughout the diffe

Answer 1

The default write concern in MongoDB has been w:1 from as far back as MongoDB 2.2 in 2012.

There are three different settings you can use to setup write concern in current MongoDB versions (version 3.2.6 and newer):

• w setting: how many nodes should acknowledge the write before declaring it a success. Default is 1, meaning the primary node's acknowledgement is sufficient.
• j setting: do the writes must be journaled before acknowledged? Default depends on writeConcernMajorityJournalDefault.
• writeConcernMajorityJournalDefault: if you specify w:majority write concern setting for your writes without setting j, what is the implied j value? Default is true (writes should be journaled in the majority of the voting nodes before it is acknowledged).

There is also a wtimeout setting to configure how long MongoDB should wait for write concern to be satisfied before informing the client that the write has not been acknowledged. Otherwise, writes waiting for write concern to be satisfied can wait forever instead of failing.

The special setting here is w:majority. This means that writes must propagate to the majority of voting nodes (and also to their journals) in a replica set to be acknowledged. This is arguably the safest setting while providing good performance, because:

• It prevents acknowledged writes to be rolled back in the event of failures.
• It regulates the application's throughput so that it won't send writes faster than what the replica set can handle (due to hardware constraints, network situation, etc.).

As you have imagined, voting nodes does include the arbiter. Thus, in a replica set with primary-secondary-arbiter setup, w:majority could fail in a scenario where:

• One of the data-bearing node is offline for some reason.
• The replica set is still online with a writable primary, since the topology is now primary-arbiter-offline.
• Writes with w:1 will succeed as usual, but those writes could be rolled back (since it was not written to the majority of voting-data-bearing nodes).
• Since the arbiter carries no data, w:majority writes will fail (or waits indefinitely) since the arbiter is counted as a voting node.

For this reason, using an arbiter is not recommended if you plan to use w:majority in your application.

Please note that using an arbiter in a 3-node replica set that forms a shard in a sharded cluster is also not recommended, since chunk moves requires w:majority. Having a data-bearing node failure in one shard will be detrimental to chunk migration operations.