WriteConcern MongoDB

What is Writeconcern in MongoDB?

Writeconcern MongoDB describes the acknowledgment level requested from the MongoDB for the write operations to be performed on sharded clusters or replica sets or to a standalone MongoDB. Write concerns will be passed to the shards in the sharded cluster.

Acknowledgement Behavior

When the write operations are acknowledged by the MongoDB instances are determined by the option w and the option j.

Standalone:
Write operation is acknowledged by a standalone mongod either after performing the writing operation to the on-disk journal or after applying the write operation in the memory. Acknowledgment behavior for a standalone and the relevant write concern above is listed in the table given below:

Replica Sets:
The value given to w tells us how many numbers of replica set members before the success must acknowledge the write. The option j for every replica set member-defined write is acknowledged by the members either after writing to the on-disk journal or after the implementation of the write operation in memory.

Specifications of MongoDB Write Concerns

The following fields are involved in the write concern:

• w option
• j option
• w timeout

Options

• w option:
  The w option is specified for the acknowledgment of the request that the propagation of the write operation to a specified number of instances of the Mongod or the Mongod instances with the tags specified. By the help of the w option, below given w: <value> write concerns are available:
  • "majority":
    "majority" write concern is the default concern for mostly all the configurations of the replica set, it requires acknowledgment that the write operations have been committed durably to a calculated majority of the data-bearing voting members.
  • <number>:
    Acknowledgment is requested that the write operation has transmitted to the number of specified Mongod instances
  • <custom write concern name>:
    Acknowledgment is requested that the write operations have transmitted to tagged members by which the custom write concern specified in settings.getLastErrorModes is satisfied.
• j option:
  option j is used to request acknowledgment that the write operation is already written to the on-disk journal.
  • If j: true, acknowledgment is requested that the mongod instances, as described in the w: <value>, required to be write on the on-disk journal.
• w timeout:
  The w timeout option is used to define the period to prevent the write operation from getting blocked indefinitely. The period in milliseconds is specified by the wtimeout. w having values greater than 1 is only applicable in the wtimeout option. There will be an error in write operations after the specified limit, even if there is the eventual success of the required write concern. At the return of these write operations, successful data changes performed before the wtimeout time limit exceeding is not undone by the MongoDB.

Suppose wtimeout option value is not specified by you in the write operation and the write concern level is unachievable, then obviously there is an indefinite block of the write operation. If we define a 0 value to the wtimeout option then it will be similar to the write concern having no wtimeout option.

Implicit Default WriteConcerns

From the MongoDB 5.0, w: majority is the implicit default write concern. But there are some special considerations made for the deployments including arbiters.

• For the replica set, the voting majority is equal to the one plus half of the voting members count(down-rounded). The default write concern is w:1 if the data bearing voting members count is not more than the voting majority count.
• w:majority is the default write concern for all other cases.

Additional Information on MongoDB WriteConcerns

Causally Consistent Sessions and Write Concerns:
Causal consistency With causally consistent client sessions is only guaranteed by the client session if:

• "majority" read concern is used in the associated read operations.
• "majority" write concern is used in the associated write operations.

Local Database does not support write concern:
The write concerns are not supported in the local database. Write concern for an operation on a collection present in the local database is silently ignored by MongoDB.

Write Concern Provenance:
From the mongoDB 4,4 provenance of the write concern is tracked by the MongoDB, by which the particular write concern source is represented.

Calculating Majority for Write Concern:
We can calculate the majority for write concern "majority" as taking the smallest from the following values:

• Taking the majority of all the available voting members( also consider arbiters) vs
• Taking all the data-bearing voting members count.

MongoDB Write Concerns for Replica Sets

Replica sets write concern specify the number of data-bearing members (such as the primary, and the secondaries but not considered arbiters) acknowledging a write operation before the successful return of the operations. For replica sets:

• w: "majority" write concern is the default concern for mostly all the configurations of the replica set, it requires acknowledgment that the write operations have been committed durably to a calculated majority of the data-bearing voting members.
• w: 1 write concern requires only primary replica set member acknowledgment prior to write concern acknowledgment return.
• Writeconcern MongoDB having the value greater than 1 requires the primary and secondary acknowldegement. And the number of secondary acknowledgments wanted to meet the value specified.