[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: |
|
||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||
| Sprint: | Server 2.7.1 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Issue Status as of May 14, 2014 ISSUE SUMMARY 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":
USER IMPACT WORKAROUNDS AFFECTED VERSIONS FIX VERSION RESOLUTION DETAILS Original descriptionWhen 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: (backport 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: | ||||||
| Comment by Githook User [ 21/May/14 ] | ||||||
|
Author: {u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}Message: | ||||||
| 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 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 Please let me know if you have additional questions. Regards, | ||||||
| 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:
Trying to clone this collection to another host now returns the same error:
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:
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, | ||||||
| Comment by Robert Jobson [ 25/Apr/14 ] | ||||||
| ||||||
| 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?
Thanks. ~ Jason Rassi | ||||||
| Comment by Robert Jobson [ 25/Apr/14 ] | ||||||
|
I was able to work around by |