[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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 Configuration A Query 1: testDB.user.find({}).readConcern("linearizable").maxTimeMS(5000) Query 2: testDB.user.find({x:1}).readConcern("linearizable").maxTimeMS(5000) Query 3: testDB.user.find({x:750}).readConcern("linearizable").maxTimeMS(5000) Configuration B Query 1: testDB.user.find({}).readConcern("linearizable").maxTimeMS(5000) Query 2: testDB.user.find({x:1}).readConcern("linearizable").maxTimeMS(5000) Query 3: testDB.user.find({x:750}).readConcern("linearizable").maxTimeMS(5000) |
| 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. |