Info

Issue Status as of May 14, 2014 ISSUE SUMMARY Prior to version 2.4.4 (and 2.2.5 in the 2.2 cycle), a call to db.createCollection() would set certain collection options to a null value rather than omitting them if they were not explicitly set by the user (see SERVER-6947 for details). Version 2.4 of the server ignored these null values, but 2.6 fails with an error message upon encountering them. This may cause problems when making copies of collections using a 2.6 server; affected commands include cloneCollection and repairDatabase. To verify if a collection is affected by this issue, inspect the system.namespaces collection of each database for any documents that have null values for options.size or options.max fields. Here is an example that shows an affected collection "test.foo": > db.system.namespaces.find() { "name" : "test.system.indexes" } { "name" : "test.foo.$_id_" } { "name" : "test.foo", "options" : { "create" : "foo", "capped" : null, "size" : null } } USER IMPACT Operations that copy collections fail with an error message. WORKAROUNDS N/A AFFECTED VERSIONS MongoDB production releases 2.6.0 and 2.6.1 are affected by this issue. FIX VERSION The fix is included in the 2.6.2 production release. RESOLUTION DETAILS The procedure that parses collection options ignores values for size and max if they are non-numeric, rather than returning an error and aborting the command. Original description When attempting to clone collection from live at version 2.4.3 to dev at version 2.6.0 recieved error. shard2:PRIMARY> db.runCommand( {cloneCollection:"homescom_reporting.realmedia_campaign_daily_sum",from:"mongodb11.dc3.homes.com:27017"} ); { "ok" : 0, "errmsg" : "BadValue size has to be a number" } Is this a cross version issue or is there a problem cloneCollection in 2.6?

Top User Comments

xgen-internal-githook commented on Sun, 25 May 2014 02:51:21 +0000: Author: {u'username': u'monkey101', u'name': u'Dan Pasette', u'email': u'dan@10gen.com'} Message: SERVER-13737 CollectionOptions parser skip size/max if non-numeric (backport 0a0ba030626243e3482830f485a3ecd79da1b7c8) Branch: v2.6 https://github.com/mongodb/mongo/commit/c02fb34f01e88c7f49d3887042f947060a4f4a90 xgen-internal-githook commented on Wed, 21 May 2014 23:48:12 +0000: Author: {u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'} Message: SERVER-13737 CollectionOptions parser skip size/max if non-numeric Branch: master https://github.com/mongodb/mongo/commit/0a0ba030626243e3482830f485a3ecd79da1b7c8 xgen-internal-githook commented on Wed, 21 May 2014 23:48:09 +0000: Author: {u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'} Message: SERVER-13737 Pull CollectionOptions out into libcollection_options.a Branch: master https://github.com/mongodb/mongo/commit/eb8b368edb239a7a698d734dedcf4f6950bf64ec robert.jobson@dominionenterprises.com commented on Fri, 25 Apr 2014 19:51:19 +0000: I would only use createCollection for rare special cases. The problem here is other users. I appreciate the additional information and I agree the cloneCollection command should be more robust whether skipping them as you suggest or allowing type 10 (null) for backwards compatibility. thomasr commented on Fri, 25 Apr 2014 19:20:00 +0000: Hi Robert, Following up on this issue, my colleague rassi@10gen.com just pointed me to SERVER-6947, which I think is the root cause of this problem. Using the db.createCollection() shell helper would create these null values prior to version 2.4.4. I believe this is where they came from in your case. The recovery steps to remove these fields in the metadata remain as described above. Additionally, I recommend that you do not use the db.createCollection() shell helper anymore until you have upgraded your system to a more recent version. You can use the create command instead, that offers the same functionality with a slightly different syntax. As SERVER-6947 is already fixed, I'm going to change this ticket and turn it into a bug against the cloneCollection command, which should skip these null values in the future, so that affected users can still clone these collections. Please let me know if you have additional questions. Regards, Thomas robert.jobson@dominionenterprises.com commented on Fri, 25 Apr 2014 19:19:09 +0000: Thanks for the information. thomasr commented on Fri, 25 Apr 2014 18:56:44 +0000: Hi Robert, The issue seems to be that the additional options "capped" and "size" each have the value null in the collection metadata. I could reproduce the problem by explicitly using the create command on a 2.4.x server and forcing these values with: > db.runCommand( { create: "null_coll", capped: null, size: null } ) { "ok" : 1 } > db.system.namespaces.find({name: "test.null_coll"}) { "name" : "test.null_coll", "options" : { "create" : "null_coll", "capped" : null, "size" : null } } Trying to clone this collection to another host now returns the same error: > db.runCommand( {cloneCollection: "test.null_coll", from: "localhost:27017"} ) { "ok" : 0, "errmsg" : "BadValue size has to be a number" } I was not able to get the same null options when using the shell helper db.createCollection(). Running a 2.6.0 server also prevented the bad options so this looks limited to an issue in the 2.4.x server (independent of the shell version). The question is how your metadata ended up with these additional fields. Can you tell me how you created the collection on the live server? Did you specify the size or capped options? Are you using any third-party tools to create collections in MongoDB? To fix this issue, you can execute the following steps during a maintenance window: copy the contents of the collection with the db..copyTo() shell command to a new collection, e.g. temp_collection drop the original collection with the db..drop() command finally rename temp_collection to the original name, with the db..renameCollection() command. After going through these steps, you can confirm that the capped and size options are no longer present in db.system.namespaces for the particular collection document. The collection should then again be clonable as expected. Note: this procedure does not retain the indexes and you would have to re-create them on the new collection. I also recommend that you take a backup of your database before executing these steps. Regards, Thomas robert.jobson@dominionenterprises.com commented on Fri, 25 Apr 2014 17:59:31 +0000: mongodbprod:PRIMARY> db.getSiblingDB("homescom_reporting").system.namespaces.find({name: "homescom_reporting.realmedia_campaign_daily_sum"}); { "name" : "homescom_reporting.realmedia_campaign_daily_sum", "options" : { "create" : "realmedia_campaign_daily_sum", "capped" : null, "size" : null } } rassi@10gen.com commented on Fri, 25 Apr 2014 15:51:59 +0000: Hi Robert, I'd like to gather additional information to further diagnose this issue. Could you connect to mongodb11.dc3.homes.com:27017 (the 2.4.3 node) with the mongo shell and paste the output of running the following? db.getSiblingDB("homescom_reporting").system.namespaces.find({name: "homescom_reporting.realmedia_campaign_daily_sum"}) Thanks. ~ Jason Rassi robert.jobson@dominionenterprises.com commented on Fri, 25 Apr 2014 14:49:21 +0000: I was able to work around by copying the collection to a new database cloning the whole new database over to dev – db.cloneDatabase(); copying the collection back into the original database on the dev server.

Steps to Reproduce