-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: 2.4.8
-
Component/s: Internal Code, Tools
-
ALL
-
0
ISSUE SUMMARY
With mongorestore v2.4.8 and earlier, mongorestore is unable to restore some collections that meet both of the following conditions:
- the create command was used to create the collection
- the collection's options were modified (through the collMod command, or through creation of a TTL or text index)
The process of updating the collection options was found in these cases to sometimes corrupt the collection metadata (as stored in the system collection system.namespaces). Other than affecting the ability for the collection to be restored with mongorestore, the corruption is benign.
USER IMPACT
When mongorestore encounters a collection affected by this issue, it will log the error message "no such cmd" and exit with a non-zero exit status. Data will only be partially restored.
SOLUTION
mongorestore was fixed to understand collection metadata that was corrupted in this way.
WORKAROUNDS
It is recommended that mongorestore v2.4.9 or greater be used to complete the restore if this issue is encountered (even if the server being restored to is using a lesser version), but the following workaround may be employed instead if a fixed version is not available:
- With a text editor, open the <collection>.metadata.json file in the dump directory for the collection that failed to be restored.
- Remove the {create: <collection>} field from the "options" subdocument.
- Repeat the restore process.
PATCHES
Production release v2.4.9 contains the fix for this issue, and production release v2.6.0 will contain the fix as well. Use mongorestore v2.4.9 or later.
Previous Description
If the "create" command is used to create a collection, the field "create" is included as the first collection option in the collection's system.namespaces entry. If the collection options are later modified, the internal update to the system.namespaces collection can re-order the "create" field such that it no longer appears first. Dumping/restoring this collection will subsequently not succeed: mongorestore will send a garbled command to the server upon attempting to re-create the collection, as it assumes that "create" is the first element in the options document (if it appears at all).
Reproduce with:
> db.createCollection("foo", {"capped" : true, "size" : 10000}) { "ok" : 1 } > db.system.namespaces.find() { "name" : "test.system.indexes" } { "name" : "test.foo.$_id_" } { "name" : "test.foo", "options" : { "create" : "foo", "capped" : true, "size" : 10000 } } > db.foo.runCommand("collMod",{usePowerOf2Sizes:true}) { "usePowerOf2Sizes_old" : false, "usePowerOf2Sizes_new" : true, "ok" : 1 } > db.system.namespaces.find() { "name" : "test.system.indexes" } { "name" : "test.foo.$_id_" } { "name" : "test.foo", "options" : { "capped" : true, "create" : "foo", "flags" : 1, "size" : 10000 } } >
Dumping/restoring this collection fails with "no such command: capped".
This does not affect mongod 2.5.x, since the update refactor causes updates to no longer re-order fields.
Original ticket description:
Run against a 2.4 mongod with textSearchEnabled=true
> db.dropDatabase()
> db.createCollection("test", { "capped" : true, "size" : 10000 })
> db.test.ensureIndex({ "a" : "text" })
> exit
$ ./mongodump
connected to: 127.0.0.1
2013-12-13T16:20:59.110-0500 all dbs
2013-12-13T16:20:59.111-0500 DATABASE: test to dump/test
2013-12-13T16:20:59.111-0500 test.system.indexes to dump/test/system.indexes.bson
2013-12-13T16:20:59.111-0500 2 objects
2013-12-13T16:20:59.111-0500 test.test to dump/test/test.bson
2013-12-13T16:20:59.112-0500 0 objects
2013-12-13T16:20:59.112-0500 Metadata for test.test to dump/test/test.metadata.json
> db.dropDatabase()
$ ./mongorestore
connected to: 127.0.0.1
2013-12-13T16:21:09.000-0500 dump/test/collection.bson
2013-12-13T16:21:09.000-0500 going into namespace [test.collection]
2013-12-13T16:21:09.245-0500 Created collection test.collection with options: { "create" : "collection", "max" : 2, "capped" : true, "size" : 100000 }
file dump/test/collection.bson empty, skipping
2013-12-13T16:21:09.245-0500 Creating index: { key: { _id: 1 }, ns: "test.collection", name: "_id_" }
2013-12-13T16:21:09.246-0500 dump/test/test.bson
2013-12-13T16:21:09.246-0500 going into namespace [test.test]
2013-12-13T16:21:09.246-0500 dev: lastError==0 won't report:Creating collection test.test failed. Errmsg: no such cmd: capped
assertion: 15936 Creating collection test.test failed. Errmsg: no such cmd: capped
I don't know the root cause of this issue. The question is whether this is something we need to backport (it works in 2.5.4).