[DOCS-1899] Comment on: "manual/release-notes/2.4-upgrade.txt" Created: 09/Sep/13 Updated: 03/Nov/17 Resolved: 17/Sep/13 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 01112017-cleanup |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Komyagin | Assignee: | Zack Brown |
| Resolution: | Done | Votes: | 0 |
| Labels: | collector-298ba4e7 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Location: http://docs.mongodb.org/manual/release-notes/2.4-upgrade/#meta-data-upgrade-procedure |
||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 10 years, 22 weeks, 1 day ago | ||||
| Description |
|
Since it's somewhat reasonable to place one of the config servers into Disaster Recovery Zone, the metadata upgrade procedure can take a very long time because of the high network latency. For the config database with 100000 chunks, the upgrade process can take up to 6 hours when latency to one of the config servers is 1-2 seconds. (it take 30-40 min when all config servers are within milliseconds ping) We should put an appropriate note saying that the metadata upgrade duration is highly dependent on the network RTT to all three config servers from the node running the 'mongos --upgrade' to set proper expectations for users. |
| Comments |
| Comment by auto [ 17/Sep/13 ] |
|
Author: {u'username': u'Zackrobat', u'name': u'Zack Brown', u'email': u'zack.brown@10gen.com'}Message: Signed-off-by: Sam Kleinman <samk@10gen.com> |