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 different mongodb versions as shows the v3.2 documentation for example:
In 3.2-versions earlier than 3.2.6, w: "majority" implies j: true if journaling is enabled. With earlier versions of MongoDB, w: majority" does not imply journaling.
Or:
Changed in version 3.0: Prior to MongoDB 3.0, w: "majority" refers to the majority of the replica set’s members.
Or:
Changed in version 2.6: In Master/Slave deployments, MongoDB treats w: "majority" as equivalent to w: 1. In earlier versions of MongoDB, w: "majority" produces an error in master/slave deployments.
Also, I'm wondering that "majority" refers to all voting nodes in v3.2 documentation :
Requests acknowledgment that write operations have propagated to the majority of voting nodes [1], including the primary.
Does this mean that even arbiters count since they are voting nodes? So, for example, if I have a replSet consisting of 2 data bearing nodes plus 1 arbiter, a write operation with write concern "majority" would succeed even if 1 data bearing node went down because the write was acknowledged by the remaining data bearing node and the arbiter, hence the majority?
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.
