[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

createIndex( .. , { verison : 3} )

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:

Type Solution Rationale
2dsphere Silently downgrade to v2 2dsphere v3 is only a performance change, not semantics change
text Error text v3 has semantics changes (i,e, unicode vs ascii only)

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 SERVER-13875.

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.

Generated at Thu Feb 08 03:52:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.