[SERVER-14761] split command should only allow NumberLongs for hashed shard keys Created: 01/Aug/14 Updated: 06/Dec/17 Resolved: 28/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.7.4 |
| Fix Version/s: | 3.5.13 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Hugh Han |
| Resolution: | Done | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Sharding 2017-07-10, Sharding 2017-07-31 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
When using a hashed shard key, the hashes are all NumberLong values. However, the split command allows splitting at values that are not NumberLongs. Such split attempts are non-sensical and should be rejected. One particular case is splitting at a double-precision value. Since doubles and NumberLongs are sorted according to the actual numeric value, this leads to chunks with double precision min/max (or mixed double/NumberLong), rather than exclusively NumberLongs. The problem gradually worsens as chunks are auto-split, until eventually However, this is still a problem in its own right, because not all NumberLongs can be represented as doubles (which is of course why NumberLongs are used in the first place). Thus, even in the absence of It is true that auto-splits are always correctly calculated as NumberLongs, but there are some situations where manual splits are required. In this case, SERVER-14217 means that it is easy to accidentally split at double precision values instead of NumberLongs. |
| Comments |
| Comment by Githook User [ 13/Jul/17 ] | ||||||||||||||||||||||||||||||
|
Author: {u'username': u'hughhan1', u'name': u'Hugh Han', u'email': u'hughhan1@gmail.com'}Message: When a shard uses a hashed key pattern, only NumberLong types may be used A small bug in hash_basic.js regarding 'middle' syntax was also fixed. A small bug in read_only_test.js regarding the shardColl(...) function | ||||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 21/Oct/15 ] | ||||||||||||||||||||||||||||||
|
No doubt it is a problem, but to me, so is this:
This resulting config doesn't really have any meaning: given that hashed indexes are always NumberLong, why should anything else be allowed? I would rather these attempted splits be refused:
Something would still need to be done about any already-existing non-NumberLong values that had made their way into hashed shard key chunk endpoints (eg. upconvert if possible?). SERVER-14217 is an exacerbating factor, and where these values often come from in the field, ie. users are trying to manually split chunks, without realising that NumberLongs are automatically and silently coerced to floats when arithmetic is done on them.
| ||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 19/Oct/15 ] | ||||||||||||||||||||||||||||||
|
Seems to me that |