MongoDB : Write concerns

Durability is that the data is written to disk and that data will be there even after a server reboot. Mongodb provides various durability options based on your requirement.

1.) Acknowledged write concern
2.) Journaled write concern
3.) MultiMember Write concerns

1.) Acknowledged write concern : provides no durability guarantee. Acknowledged meand that mongo updates its in memory view with the write. It said nothing that data is anywhere on disk. there is also unacknowledgd write, which just write the data and raise concern only if there is syntax error.

2.) Journaled write concern: with Journaled write concern mongo will hold of returning OK untill write has made it  into the journal. the journal is flushed to disk fairly often, so your maximum wait has a fairly low upper bound to begin with. Once a document is in the journal and on disk , a machine restart will be able to apply data. this is a minimal guarantee.

3.) MultiMember Write concerns: you can supply a write concerns that states one or more members have to acknowledge the write. Both a write concern of one and the acknowledge write concern; get the single member response from the primary. After all any wrtie in mongo has to go to primary first. So it the primary provides acknowkdge of one in both cased. A write concern of 2 means, that mongo will acknowlgde a write only after 2 members have acknowldged it. Any number higer that 1, mongo will wait for that many members to acknowdge the write and say OK to the application. this is a higer degree of durability.
Another convientt way to specify replication based write concern is to pass the majority flag. This flag means the acknowlgement by as may as the majority of member need to acknowlge the write.

From version 3.0 onwards, majority means , majority of voting members.

## Timeouts:
When you are using a multimember write concern, you are increasing the risk that one of the members will be slow, blocking or unavailable.
What is desired no of acknowldgement cant be achived, then what? surely , your client would wnat some failure indication, also it would be nice to specify some timeouts.
Such as if you cant get the acknowlegment in 3 seconds, return anyway. This kind of balance in the application be reponsive in the fase of slowneess or secondary memebr temporarily unavailable.
if the timeout has elapsed but the write concern has not been fulfilled, the application will recive an error indication. A timeout specific error so the application can detect the cause.
this condition dont cancel the write and does not roll back anything. All it does is let the application continue on and put a maximum bound of time tat that write will take. Provide an SLA to the applications.

Example:

1.) No Gurantee about nothing:

r1:PRIMARY> use demo
switched to db demo
r1:PRIMARY> db.demo.insert({x:'hi'},{writeConcern: {w:0}})
WriteResult({ })
r1:PRIMARY>

you can see the write didnt give an acknowlegement. if the server is re-started before this docuemtn make it to the disk, this document could be lost forever.

Now i will ask the write concern to be persisted to disk, write concern to be journaled equals true. 

2.) Journaled write conerns. j is for journaled.

r1:PRIMARY> db.demo.insert({x:'hi'},{writeConcern: {j: true}})

WriteResult({ "nInserted" : 1 })

r1:PRIMARY>

it returned that 1 document is written and more important if the server is restarted the data wil be available. 

3.) MultiMember Write concern: i am gonna ask for acknowlegde from 1 server.

r1:PRIMARY> db.demo.insert({x:'hifor 1'},{writeConcern: {w:1}})
WriteResult({ "nInserted" : 1 })
r1:PRIMARY>  db.demo.find()
{ "_id" : ObjectId("5d6fa0dcf20b6b8747ecd220"), "x" : "hi" }
{ "_id" : ObjectId("5d6fa0f2f20b6b8747ecd221"), "x" : "hi" }
{ "_id" : ObjectId("5d6fa101f20b6b8747ecd222"), "x" : "hi" }
{ "_id" : ObjectId("5d6fa282f20b6b8747ecd223"), "x" : "hifor 1" }

now i gonna ask for 2 members to acknowledge my wrtie

r1:PRIMARY> db.demo.insert({x:'hifor 1'},{writeConcern: {w:2}})

WriteResult({ "nInserted" : 1 })

r1:PRIMARY>  db.demo.find()

{ "_id" : ObjectId("5d6fa0dcf20b6b8747ecd220"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa0f2f20b6b8747ecd221"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa101f20b6b8747ecd222"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa282f20b6b8747ecd223"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa295f20b6b8747ecd224"), "x" : "hifor 1" }

r1:PRIMARY>

Here the "j" parameter is for journaled and "w" for write. Journaled and write concerns of multiple servers are not mutually exclusive. So i can say that, i want mongo to only acknowledge after the write has made it to the journal and two members have acknowledged. 

r1:PRIMARY> db.demo.insert({x:'hifor 1'},{writeConcern: {w:2, j:true}})

WriteResult({ "nInserted" : 1 })

r1:PRIMARY> db.demo.find()

{ "_id" : ObjectId("5d6fa0dcf20b6b8747ecd220"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa0f2f20b6b8747ecd221"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa101f20b6b8747ecd222"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa282f20b6b8747ecd223"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa295f20b6b8747ecd224"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa397f20b6b8747ecd225"), "x" : "hifor 1" }

r1:PRIMARY>

Now if i want to get acknowledged my the majority field of the replica set then

r1:PRIMARY> db.demo.insert({x:'hi for majority'},{writeConcern: {w:'majority'}})

WriteResult({ "nInserted" : 1 })

r1:PRIMARY> db.demo.find()

{ "_id" : ObjectId("5d6fa0dcf20b6b8747ecd220"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa0f2f20b6b8747ecd221"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa101f20b6b8747ecd222"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa282f20b6b8747ecd223"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa295f20b6b8747ecd224"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa397f20b6b8747ecd225"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa3e1f20b6b8747ecd226"), "x" : "hi for majority" }

r1:PRIMARY>

_____________________________________________________________

Example for timeout: Lets kill one member and then ask for acknowledgemtn from 3 members.

[mongod@sikki4u2c ~]$ ps -ef| grep mongod

mongod    7486     1  0 11:30 ?        00:00:05 mongod --dbpath /home/mongod/m1 --port 30001 --replSet r1 --logpath /var/log/mongodb/mongod_m1.log --fork

mongod    7518     1  0 11:31 ?        00:00:04 mongod --dbpath /home/mongod/m2 --port 30002 --replSet r1 --logpath /var/log/mongodb/mongod_m2.log --fork

mongod    7547     1  0 11:31 ?        00:00:04 mongod --dbpath /home/mongod/m3 --port 30003 --replSet r1 --logpath /var/log/mongodb/mongod_m3.log --fork

[mongod@sikki4u2c ~]$ kill 7547

I am now with 2 members alive and write concerns for 3 member with timeout of 2 seconds

r1:PRIMARY> db.demo.insert({x:'hi for timeout'},{writeConcern: {w:3, wtimeout:2000}})

WriteResult({

        "nInserted" : 1,   -- it inserted even after a timeout

        "writeConcernError" : {

                "code" : 64,

                "codeName" : "WriteConcernFailed",

                "errInfo" : {

                        "wtimeout" : true --- timeout was true

                },

                "errmsg" : "waiting for replication timed out"

        }

})

r1:PRIMARY>

this error does not mean that the document wasnt persisted anywhere, it just means the document didnt get acknowledgement from 3 members before the timeout. And the docuemnt may have made it to the secondary. 

r1:PRIMARY> db.demo.find()

{ "_id" : ObjectId("5d6fa0dcf20b6b8747ecd220"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa0f2f20b6b8747ecd221"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa101f20b6b8747ecd222"), "x" : "hi" }

{ "_id" : ObjectId("5d6fa282f20b6b8747ecd223"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa295f20b6b8747ecd224"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa397f20b6b8747ecd225"), "x" : "hifor 1" }

{ "_id" : ObjectId("5d6fa3e1f20b6b8747ecd226"), "x" : "hi for majority" }

{ "_id" : ObjectId("5d6fa4bff20b6b8747ecd227"), "x" : "hi for timeout" }