[SERVER-23716] Stop sending init form of setShardVersion Created: 14/Apr/16 Updated: 05/Apr/17 Resolved: 23/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.3.4 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | PM-108 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2017-01-02, Sharding 2017-02-13 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
In addition, mongos now needs to start sending setShardVersion (0,0) before sending requests to unsharded collections, otherwise, the connection will never have ShardedConnectionInfo and no version checking will take place for that connection. In other words, if the collection was actually sharded, the shard will not throw a stale shard version exception. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 23/Jan/17 ] |
|
Fixed by https://jira.mongodb.org/browse/SERVER-27625. The init form of setShardVersion is still sent solely to initialize a connection as 'sharded', but it no longer causes sharding initialization on the shard. |
| Comment by Spencer Brody (Inactive) [ 14/Apr/16 ] |
|
Hmm... that part about sending the (0,0) version for unsharded operations is a bit scary. How are we going to ensure we haven't missed any places that operate on unsharded collections? Makes me wonder if we might be better off continuing to send the init form of SSV until we can kill SSV entirely as part of |