[SERVER-13737] CollectionOptions parser should skip "size"/"max" elements if values non-numeric Created: 25/Apr/14  Updated: 11/Jul/16  Resolved: 21/May/14

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.4.10
Fix Version/s: 2.6.2, 2.7.1

Type: Bug Priority: Major - P3
Reporter: Robert Jobson Assignee: J Rassi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-13927 Copydb breaks on (some) capped collec... Closed
related to SERVER-13968 Report invalid collection options in ... Closed
is related to SERVER-6947 db.createCollection creates undefined... Closed
is related to SERVER-16293 repairDatabase causes "size has to b... Closed
Backport Completed:
Sprint: Server 2.7.1
Participants:

 Description   
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?



 Comments   
Comment by Githook User [ 25/May/14 ]

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

Comment by Githook User [ 21/May/14 ]

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

Comment by Githook User [ 21/May/14 ]

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

Comment by Robert Jobson [ 25/Apr/14 ]

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.

Comment by Thomas Rueckstiess [ 25/Apr/14 ]

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

Comment by Robert Jobson [ 25/Apr/14 ]

Thanks for the information.

Comment by Thomas Rueckstiess [ 25/Apr/14 ]

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:

  1. copy the contents of the collection with the db.<collection>.copyTo() shell command to a new collection, e.g. temp_collection
  2. drop the original collection with the db.<collection>.drop() command
  3. finally rename temp_collection to the original name, with the db.<collection>.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

Comment by Robert Jobson [ 25/Apr/14 ]

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 } }

Comment by J Rassi [ 25/Apr/14 ]

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

Comment by Robert Jobson [ 25/Apr/14 ]

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.

Generated at Thu Feb 08 03:32:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.