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

Question

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](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?

Answer

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.

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

Relevant content