[MongoDB]: How to use Write Concerns
This post describe on how to use write concerns in MongoDB and how it impacts durability, performance and resiliency.
Write Concerns: This describes the level of concern or guarantee the server will provide in its response to a write operation. w, j and wtimeout together constitute Write Concerns.
‘w’ : Parameter determines how many nodes we wait for before you move on when you do an insert. For example: On a 3 node replica set, setting w=1: will just wait for Primary to acknowledge the write. w=2: wait for Primary and one other node (secondary) to acknowledge the write. w=3: wait for Primary and 2 other nodes (secondary) to acknowledge the write.
w= majority: will wait for majority of the nodes to replicate .Confirms that write operations have propagated to the majority of configured replica set: nodes must acknowledge the write operation before it succeeds. This ensures that write operation will never be subject to a rollback in the course of normal operation.
The first thing we need to understand is that MongoDB separates the writing of the data from the acknowledgement. They are in fact two different commands. So when the driver does a non acknowledge write using w: 0 it only sends the write command. If your application needs to be written to memory acknowledgement with w: 1 it will send a write command and a getLastError command together.
The getLastError command is the command that returns the status of the last executed operation on a specific socket.
mongo
MongoDB shell version: 2.2
connecting to: test
> use test
switched to db test
> db.getlasterrortest.insert({_id: 1})
E11000 duplicate key error index: test.getlasterrortest.$_id_ dup key: { : 1.0 }
> db.getLastError()
E11000 duplicate key error index: test.getlasterrortest.$_id_ dup key: { : 1.0 }
> db.getlasterrortest.insert({_id: 2})
> db.getLastError()
null
journaled:The mongod will confirm the write operation only after it has written the operation to the journal. This confirms that the write operation can survive a mongod shutdown and ensures that the write operation is durable.
j= true. MongoDB acknowledges when the document has been safely written to the MongoDB journal. This waiting for commit to journal is only on primary node not on secondary nodes.
fsync:true. MongoDB acknowledges when the document has been safely written to disk
wtimeout : How long to wait for the writes to be acknowledged by secondary’s. wtimeout= 0 Indefinite & >0 ms to wait.
| WriteConcern | Description |
| w:0 | No acknowledgement of the write from MongoDB |
| w:1 | MongoDB acknowledges when the document has been safely written to memory |
| w:2 or larger | MongoDB acknowledges when the document has been safely written to memory in N servers |
| w:’majority’ | MongoDB acknowledges when the document has been safely written to memory in a majority of servers (ex if you have 1 primary and 4 secondary’s this would be 3 servers as 3 out of 5 is a majority of servers) |
| j:true | MongoDB acknowledges when the document has been safely written to the MongoDB journal |
| fsync:true | MongoDB acknowledges when the document has been safely written to disk |
Setting Default Write Concern:
The default writeconcern can be set at different levels. MongoClient already comes with the default write concern set to w: 1 but your application can set it at the Db, Collection or individual operation. Let’s enter some example code showing how to set it at different levels.
var mongodb = require(‘mongodb’)
, MongoClient = mongodb.MongoClient;
MongoClient.connect(“mongodb://localhost:27017/test?w=0”, function(err, db) {
if(err) {
console.log(“failed to connect to the database”);
} else {
console.log(“connected to database”);
}
var collection = db.collection(‘my_write_concern_docs’);
collection.insert({_id:1});
var collectionWithWriteConcernSet = db.collection(‘my_write_concern_docs’, {w:1});
collectionWithWriteConcernSet.insert({_id:1}, function(err, result) {
if(err) {
console.log(“write concern on collection caught duplicate key error”);
When you run the script the output should look something like this.
connected to database
write concern on collection caught duplicate key error
write concern on collection caught duplicate key error
Note: When “w:n” is specified and the nodes are lost due to an outage, there is the risk that if ‘n’ is greater than the number of surviving nodes, the write operation may wait forever. This scenario can be circumvented by setting “w: majority”. In the event that you lose enough nodes such that you don’t have a majority, the database remains in read-only mode as no primary can be elected.
One of the things to keep in mind about write concerns is that the cost of higher guarantees of durability comes with an insert performance cost. So think carefully if you need your documents to be replicated across multiple secondaries or if you are good enough with them being acknowledged as written to the memory of the primary server. A typical mistake is to be too paranoid about losing data and setting the highest possible durability you can do and getting very bad insert performance as a consequence.