Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-12092

Modifying collection options can cause restores of collection to fail

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 2.4.8
    • Fix Version/s: 2.4.9, 2.5.5
    • Component/s: Internal Code, Tools
    • Labels:
    • Operating System:
      ALL
    • Linked BF Score:
      0

      Description

      Issue Status as of December 30th, 2013

      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).

        Attachments

          Activity

            People

            Assignee:
            rassi J Rassi
            Reporter:
            sverch Shaun Verch
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: