[SERVER-25561] Backwards compatibility issues when sending linearizable reads to multiversion sharding cluster Created: 11/Aug/16  Updated: 11/Nov/16  Resolved: 10/Nov/16

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Hari Devaraj Assignee: William Schultz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File linearizable_shard_read.js    
Issue Links:
Related
is related to SERVER-24498 Write tests for linearizable reads in... Closed
Operating System: ALL
Sprint: Repl 2016-11-21
Participants:

 Description   

If a linearizable read in a sharded cluster targets multiple shards (we do not disallow this even though linearizability cannot be guaranteed on more than 1 document), one of which is a replica set updated to 3.4 and another is only on version 3.2, the linearizable read command might succeed on the 3.4 set and return linearizable read not supported on the 3.2 set. We need to make sure mongos knows how to respond to this situation.



 Comments   
Comment by Spencer Brody (Inactive) [ 10/Nov/16 ]

It is illegal to issue a linearizable read that targets multiple documents, and if the query hits a 3.2 shard it correctly reports that the read concern isn't recognized.

Comment by William Schultz (Inactive) [ 10/Nov/16 ]

spencer Investigation results with a couple of sharded cluster configurations. It seems that any queries which target a 3.2 shard will return the error messages shown below when specifying linearizable readConcern. The JS test script used to obtain these results is attached (variable values can be tweaked).

General Configuration

2 shards, 1 mongos
"test.user" collection with documents { x : [1...1000], name: "test" }
shardkey: "x",
shard1 key range: {x:1}...{x:500}
shard2 key range: {x:501}...{x:1000}

Configuration A
mongos: v3.2
shard1: v3.2
shard2: v3.4

Query 1: testDB.user.find({}).readConcern("linearizable").maxTimeMS(5000)
Response 1:{{Error: error: {"ok" : 0, "errmsg" : "readConcern.level must be either 'local' or 'majority'", "code" : 9 }}}

Query 2: testDB.user.find({x:1}).readConcern("linearizable").maxTimeMS(5000)
Response 2: Error: error: { "ok" : 0, "errmsg" : "readConcern.level must be either 'local' or 'majority'", "code" : 9 }

Query 3: testDB.user.find({x:750}).readConcern("linearizable").maxTimeMS(5000)
Response 3 (first doc of cursor): { "_id" : ObjectId("5824a830a58daf50ae382d7c"), "x" : 750, "name" : "test" }

Configuration B
mongos: v3.4
shard1: v3.4
shard2: v3.4

Query 1: testDB.user.find({}).readConcern("linearizable").maxTimeMS(5000)
Response 1 (first doc of cursor): { "_id" : ObjectId("5824a969320116512382f733"), "x" : 1, "name" : "test" }

Query 2: testDB.user.find({x:1}).readConcern("linearizable").maxTimeMS(5000)
Response 2 (first doc of cursor): {{ { _id : ObjectId5824aa8626ac951c5b95adc6, "x" : 1, "name" : "test" } }}

Query 3: testDB.user.find({x:750}).readConcern("linearizable").maxTimeMS(5000)
Response 3 (first doc of cursor): { "_id" : ObjectId("5824aaf86bcf288abd7da99b"), "x" : 750, "name" : "test" }

Comment by Eric Milkie [ 27/Oct/16 ]

But using a limit of 1 isn't going to ensure that you are using it correctly. Instead, it would force people to manually insert a limit where it actually isn't necessary. All that is necessary is that the query specification uniquely identifies one document, based on the properties of the collection you are querying.

Comment by Spencer Brody (Inactive) [ 26/Oct/16 ]

Isn't the real fix to not allow linearizable reads unless the query's limit is 1? Linearizable reads don't work properly for multi-document reads, so we should disallow them.

Generated at Thu Feb 08 04:09:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.