By using AWS re:Post, you agree to the Terms of Use

DocumentDB mongorestore index fails to create with error 303: Field currently not supported

0

I have a DocDB instance running the 4.0 engine version. As stated here: https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html#mongo-apis-index, 2dsphere indexes are supported in this engine version, and that is correct, I have been able to create 2dsphere indexes.

The problem comes when the index gets created. Default option fields will be added to the index metadata when created, and between those, the v field and the 2dsphereIndexVersion field will be added to the index metadata options. These are the fields that are not supported when trying to restore an index definition from a mongodump containing a 2dsphere index.

Steps to reproduce:

Create the index:

db.collection.createIndex({ loc : "2dsphere" })

Default option fields will be added to the index:

{ 
    "v" : 4, 
    "name" : "loc_2dsphere", 
    "ns" : "db.field", 
    "2dsphereIndexVersion" : 1
}

So, when running a mongodump, the dump will contain this index metadata. Then, when trying to run a mongorestore of that dump, you get an error like this:

{ 
    "ok" : 0.0, 
    "code" : 303.0, 
    "errmsg" : "Field '2dsphereIndexVersion' is currently not supported", 
    "operationTime" : Timestamp(1657665107, 1)
}

or

{ 
    "ok" : 0.0, 
    "code" : 303.0, 
    "errmsg" : "Field 'v' is currently not supported", 
    "operationTime" : Timestamp(1657665203, 1)
}

mongorestore can be run with --noIndexRestore option but is there a way to restore the indexes?

1 Answer
0

Hello. Mongodump does not backup the actual indexes, just their definition, a piece of metadata that mongorestore will use to create the type of index on the specified field or fields. The recommended approach is exactly what you tried, pre-create the indexes on the empty collection, then restore with the --noIndexRestore option. This is also preferred because you get faster restore, creating an index on existing data is a single threaded operation which can take a long time on a large dataset. But restoring with a pre-existing index, along with the --numInsertionWorkersPerCollection option (match this with number vCPUs) will yield much faster restore times.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions