The difference between “majority” and “linearizable”

Question

Read the docs a few times but still cannot understand the difference in the behavior of "majority" and "linearizable" read concerns:

Answer 1

"Linearizable" read concern was introduced in MongoDb 3.4 to solve a possible issue with "majority" Read concern.

Lets try to understand the problem with "majority" read concern to sense what "Linearizable" brings to us.

Suppose, we have a replicaset of 3 nodes, which looks something like this:

Where, A is Primary, B is Secondary, C is Secondary

Lets also have two users Alice and Bob, which will be performing some operations on following document which resides in "users" collection.

{
 "_id": 100234,
 "name": "Katelyn"
}

At time instant T0:

following happens,

1. Alice gets connected to A (primary) and issues following command.

db.users.find({"_id":100234}); --> with read concern 'majority'

Output:

{ "_id" : 100234, "name" : "Katelyn" }

2. B and C realizes that A has stopped responding and starts election procedure.(May be due to network partitioning).

At time instant T1:

following happens,

1. Due to the election process, B stands as a new primary.

However, till the time A is not communicated or A itself realizes that it needs to demote itself to a secondary it continues serving as a primary (this is generally for a very small period of time though).

At time instant T2:

1. Bob gets connected to B (new primary) and issues following command.

db.users.update( {"_id":100234}, {$set: {name:"Sansa"} } ); --> with write concern 'majority'.

2. Bob is acknowledged of write.

At time instant T3:

1. Alice gets connected to A (old primary) and issues following command.

db.users.find({"_id":100234}); --> read concern 'majority'

Output:

{ "_id" : 100234, "name" : "Katelyn" }

Alice here gets the stale data even after issuing the majority read concern, i.e the write made by Bob is not visible to Alice. Thus, the property of "Linearizability" is compensated in this case.

Definition of Linearizability: writes should appear to be instantaneous. Imprecisely, once a write completes, all later reads (where “later” is defined by wall-clock start time) should return the value of that write or the value of a later write. Once a read returns a particular value, all later reads should return that value or the value of a later write.

Hence, comes the solution i.e "linearizable" read concern. With this property, mongod checks its primary and can see majority of nodes before issuing the results of read operation. However, there is a performance cost penality of using this Read Concern over "majority", thus this is not a replacement for "majority" read concern.

---

Regarding writeConcernMajorityJournalDefault property, it is merely a replica set configuration option. It accepts boolean value.

True means, MongoDB acknowledges the write operation after a majority of the voting members have written to the on-disk journal.

False means, MongoDB acknowledges the write operation after a majority of the voting members have applied the operation in memory.

The above property is applicable only when, write concern "majority" is used and journaling flag is not specified.

Answer 2

In my understanding, Read Concern majority in an node will immediately return the read query with the most recent data written in that node. On the other hand, Read Concern linearizable will wait till the completion concurrently executing writes to propagate to a majority of replica set members before returning results.

Both of them guaranty that the data read has been acknowledged by a majority of the replica set members, i.e. the documents read are durable and guaranteed not to roll back.

As Read Concern linearizable waits for the concurrently executing writes to be finished, it's performance is significantly slower than that of Read Concern majority.

Similarly, since Read Concern majority don't wait for the concurrently executing writes, it will return fast, but it may return stale data(still durable & w:majority acknowledged). See this example for details: https://docs.mongodb.com/manual/reference/read-concern-majority/#example

In that example between t3~t5 (after t3 and before t5) primary and secondaries will return different data with Read Concern majority.