[SERVER-13487] Incorrect mongos shard routing for some range based finds on single shard key Created: 04/Apr/14 Updated: 10/Dec/14 Resolved: 16/May/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.6.0-rc2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Paul Done | Assignee: | Greg Studer |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||
| Operating System: | ALL | |||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||
| Participants: | ||||||||||||||||
| Description |
|
MongoDB version: 2.6.0rc2 When running a query against a sharded collection using a range in the find() criteria based on values in the shard key, depending on the range of values used, the mongos / query optimiser is incorrectly targeting 2 shards when it only needs to target 1 shard. Specifically, the problem is for a sharded collection that has a single (non-compound) shard key, and $lte (or $gte) is used in the range query. The exact behaviour can be seen when running .explain(). Say I have a sharded collection on shard key "myfield" and in shard s1 a chunk exists for {"myfield":80}-->>{"myfield":1059} and then in shard s0 a chunk exists for {"myfield":1059}-->>{"myfield":2492}, then when I issue a find() with criteria "$lt: 1059", both shards s1 and s0 are routed to when only one shard (s1) needs to be routed to. As a workaround, if I modify the criteria to be "$lte: 1058", then only one shard (s1) is correctly routed to. HOWEVER, this means my generic query code for my more real world application has to be explicitly aware of field types (no schema) and the knowledge that the field actually contains an integer that can be possible decremented by 1, just to try to optimise the sharded query. |
| Comments |
| Comment by Siyuan Zhou [ 16/May/14 ] |
|
Yes. It is because the post-process of the index bounds doesn't respect inclusive/exclusive. This is an known issue. I am closing it as a dup. |
| Comment by Adam Comerford [ 04/Apr/14 ] |
|
I've reproduced this, the root of the problem seems to be that the index bounds being produced by $lt and $lte (and $gt, $gte) are identical. For example, if you specify criteria {$gte : 2000, $lte : 3000} you get index bounds of [2000, 3000]. However, if you specify criteria {$gt : 2000, $lt : 3000} you get the identical index bounds of [2000, 3000] rather than the expected [2001, 2999] based on the previous result. Hence when querying for ranges that coincide with the chunk boundaries you can unexpectedly hit more chunks (and hence shards) than you would expect. |