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:

"majority"
The query returns the instance’s most recent data acknowledged as having been written to a majority of members in the replica set.

"linearizable"
The query returns data that reflects all successful writes issued with a write concern of "majority" and acknowledged prior to the start of the read operation.

The docs also mention an option "writeConcernMajorityJournalDefault", it says that with that option set to false the data can be rolled back even when using "linearizable".

Could someone explain please, how both concerns work and how this option impacts them?

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.