[DOCS-2920] Comment on db.upgradeCheck() and db.upgradeCheckAllDbs() Created: 17/Mar/14  Updated: 20/Mar/14  Resolved: 20/Mar/14

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: v1.3.2, mongodb-2.6

Type: Improvement Priority: Major - P3
Reporter: Linda Qin Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by DOCS-2746 reformat example in "steps-enable-aut... Closed
Participants:
Days since reply: 9 years, 47 weeks, 6 days ago

 Description   

http://docs.mongodb.org/master/reference/method/db.upgradeCheck/
http://docs.mongodb.org/master/reference/method/db.upgradeCheckAllDbs/

  1. Clarify the performance impact to run db.upgradeCheck() and db.upgradeCheckAllDbs()
    db.upgradeCheck() and db.upgradeCheckAllDbs() validates all the document in the given collections. This looks like a collection scan, and might affect the performance on a production environment. If it is true, can you add this warning in the document?
  2. If it is a sharded cluster/replica set, it would be nice to document which nodes we should run db.upgradeCheck() or db.upgradeCheckAllDbs().


 Comments   
Comment by Githook User [ 20/Mar/14 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-2920 specify nodes to run against and access info
Branch: master
https://github.com/mongodb/docs/commit/130cf6321f38d4229130d17fb0c9ac67e976cb87

Comment by Matt Dannenberg [ 18/Mar/14 ]

1. It does do collection scans and it is worth adding a warning about that.

2. I agree with what you've come up with. Turning off the balancer would be a good idea, but I believe it would just miss possible problems if you don't (it wouldn't explode or anything). We should probably have someone run it against the assorted configurations (sharded, replicaset) to ensure we haven't missed any blatant problems.

Generated at Thu Feb 08 07:44:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.