[SERVER-19971] Multiversion shards should work with v3 2dSphere indexes; v3 text indexes Created: 14/Aug/15 Updated: 23/Sep/15 Resolved: 23/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Albertson | Assignee: | Eric Milkie |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Platform 9 (09/18/15), RPL A (10/09/15) |
| Participants: |
| Description |
|
If you have a mongod 3.0 shard (which has 2dsphere index version 2 as default) and a mongod 3.1.6+ shard (which has 2dsphere index version 3 as default), they will have different 2dsphere index versions if you build an index. This should work without issue since version 3 does not change any semantics. However, when a chunk moves from a mongod 3.1.6 shard to a mongod 3.0 shard, it triggers the uassert here: https://github.com/mongodb/mongo/blob/v3.0/src/mongo/db/index/s2_access_method.cpp#L97-L101 I believe this occurs when attempting to check if the indexes are equivalent on the receiver shard. |
| Comments |
| Comment by Eric Milkie [ 23/Sep/15 ] | ||||||||||
|
We're not going to do anything further for this; it will be up to the user not to run the balancer on a mixed-version sharded cluster. If they still run the balancer, nodes will shut down (instead of leaving the data in a bad state or downconverting indexes silently). | ||||||||||
| Comment by Mark Benvenuto [ 11/Sep/15 ] | ||||||||||
|
It is not possible to differentiate the two situations though. S2AccessMethod::fixSpec will inject the 2dsphereIndexVersion field into the index spec, and once it is there, we cannot tell if the user specified it, or if the system implicitly added it. | ||||||||||
| Comment by Siyuan Zhou [ 11/Sep/15 ] | ||||||||||
|
If the { version: 3 } is given explicitly, I doubt the user would expect a silent downgrade to v2. Currently creating 2dsphere index of version 3 on mongodb 3.0 will give an error as expected. This problem described above happens in sharding, since 3.2 mongod will modify the index spec by adding { 2dsphereIndexVersion: 3 } if the filed is absent. The 3.0 receiver shard saw that modified index spec and rejects it. | ||||||||||
| Comment by Mark Benvenuto [ 11/Sep/15 ] | ||||||||||
|
After discussion, the problem is what are the semantics of
on a version of the product that does not support version 3 indexes, i.e, MongoDB 3.0. Here is the proposal based on the original description and title:
I have implemented the 2dsphere changes, but it still feels weird because we are silently changing the index version on the user. I rather it would fail personally then silently change the semantics on the user. | ||||||||||
| Comment by Eric Milkie [ 27/Aug/15 ] | ||||||||||
|
Step 1 disables the balancer but it was never explicitly stated that moving chunks wasn't supported in a mixed-version sharded cluster. The work for this ticket isn't that much for the amount of benefit so I think we should move ahead. | ||||||||||
| Comment by J Rassi [ 27/Aug/15 ] | ||||||||||
|
See related ticket I was under the impression that we didn't support migrations during the upgrade process; our 3.0 upgrade documentation lists "disable the balancer" as step #1. Are we sure we have any work to do here? | ||||||||||
| Comment by Eric Milkie [ 25/Aug/15 ] | ||||||||||
|
Need to mention this in release notes for 3.2 upgrade. |