[SERVER-12175] Version 2dsphere indexes Created: 20/Dec/13  Updated: 11/Jul/16  Resolved: 15/Feb/14

Status: Closed
Project: Core Server
Component/s: Geo
Affects Version/s: 2.5.4
Fix Version/s: 2.4.10, 2.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: J Rassi Assignee: J Rassi
Resolution: Done Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-12914 mongod 2.4 should not start if unknow... Closed
is related to SERVER-13096 Add 2.4/2.6 multiversion tests for te... Closed
Operating System: ALL
Participants:

 Description   
Issue Status as of March 28, 2014

ISSUE SUMMARY
This issue introduces versions for 2dsphere indexes. This was necessary as new features were added to 2dsphere indexes in MongoDB version 2.6, for example support for new GeoJSON objects like MultiPoint and GeometryCollection. A downgrade from version 2.6 to 2.4 would otherwise not be able to detect the new index implementation and could potentially corrupt the index.

USER IMPACT
Users are affected if they use a 2dsphere index with any of the new GeoJSON documents in version 2.6 (which are MultiPoint, MultiLineString, MultiPolygon and GeometryCollection) and then downgrade to version 2.4. This can cause index corruption and return wrong query results.

SOLUTION
Introduce versions for 2dsphere indexes, include checks for version 1 (old format) 2dsphere indexes if it indexes a geometry that was introduced in later versions (e.g. MultiPoint).

WORKAROUNDS
Users who want to downgrade mongod from version 2.6 to 2.4 should drop the 2dsphere index before the downgrade.

AFFECTED VERSIONS
All versions from 2.4.0 to 2.4.9 are affected.

PATCHES
The fix is included in the production release 2.4.10.

Original Description

Add new index option "2dsphereIndexVersion" to 2dsphere indexes.

Version 1 can't index MultiPoint, MultiLineString, MultiPolygon, or GeometryCollection (index build will fail if docs present, and inserting doc will fail if index present). Version 2 can index these.

2.4 builds version 1 indexes, and cannot build/use version 2 indexes. Drop version 2 indexes before downgrading 2.6=>2.4.

2.6 builds version 2 indexes by default, and is able to build/use version 1 too.

Original description:

Documents with 2.6-only GeoJSON types can be missing _id index entries after 2.4 downgrade

The GeoJSON types MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection were introduced in 2.5. As such, version 2.4 of the server cannot unindex these documents from 2dsphere indexes. Attempting to delete such a document after downgrading 2.6=>2.4 will cause the document to be only half-removed: it will be successfully removed from the lower-numbered indexes (like the _id index), but will remain in the 2dsphere and higher-numbered indexes, and will remain in the collection.

Having a collection with missing index entries is problematic, especially for the _id index. Running mongodump against the mongod will generate a dump that is missing these documents (since a snapshot query is issued). If the mongod later becomes a secondary, it will fail to apply updates from the oplog against these documents (since the oplog writers locate such documents with the _id index).

Reproduce with the following, in 2.5.4:

> db.foo.ensureIndex({loc:"2dsphere"})
> db.foo.insert({loc:{type:"MultiPoint",coordinates:[[-73.9580, 40.8003]]}})
Insert WriteResult({ "ok" : 1, "nDocsModified" : 0, "n" : 1 })

Followed by the following, after downgrading to 2.4.8:

> db.foo.validate().keysPerIndex
{ "test.foo.$_id_" : 1, "test.foo.$loc_2dsphere" : 1 }
> db.foo.remove(); db.getLastError()
Can't extract geo keys from object, malformed geometry?:{ type: "MultiPoint", coordinates: [ [ -73.958, 40.8003 ] ] }
> db.foo.validate().keysPerIndex
{ "test.foo.$_id_" : 0, "test.foo.$loc_2dsphere" : 1 }
> db.foo.find().hint({$natural:1}).itcount()
1
> db.foo.find().hint({_id:1}).itcount()
0

At the default logging severity, no log output is generated for this error.



 Comments   
Comment by Daniel Pasette (Inactive) [ 20/Feb/14 ]

jhn, yes. in 2.6, 2dsphere indexes will behave exactly as 2d indexes with regards to sparse rules. I'll add exact information in SERVER-9639.

Comment by Johan Hedin [ 16/Feb/14 ]

Can this new version tag be used to resolve this issue as well: https://jira.mongodb.org/browse/SERVER-9639 ?

Comment by Githook User [ 15/Feb/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-12175 Reject 2dsphere idxs w/o supported 2dsphereIndexVersion

Refuse to use/build if 2dsphereIndexVersion index option is set and
has any value other than 1.
Branch: v2.4
https://github.com/mongodb/mongo/commit/7736ee885b28295a60ba39f9f6d7d59beb35b34f

Comment by Githook User [ 15/Feb/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-12175 Add 2dsphere index option "2dsphereIndexVersion"

  • Defines version 1 and 2; both are supported.
  • Indexes without this option are assumed to be version 1.
  • New builds get version 2 (if version unspecified).
  • Version 1 throws in getKeys if the geometry is one of the types
    introduced since 2.4.0 (MultiPoint, MultiLineString, MultiPolygon,
    GeometryCollection).
    Branch: master
    https://github.com/mongodb/mongo/commit/ecda90ce4ac91aea66f076aacbbe28f7286a7351
Generated at Thu Feb 08 03:27:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.