[DOCS-4514] Instructions for Restore a Sharded Cluster make a number of assumptions Created: 15/Dec/14 Updated: 11/Jan/17 Resolved: 27/Jul/16 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | production |
| Affects Version/s: | None |
| Fix Version/s: | 01112017-cleanup |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Victor Hooi | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 7 years, 29 weeks ago | ||||||||
| Description |
|
The documentation page for "Restore a Sharded Cluster" makes a number of implicit assumptions. These assumptions should be explicitly mentioned in the documentation, in order to avoid confusion. Firstly, the documentation assumes that you are either restoring onto the same hostnames, or if not, then you are restoring onto new hostnames where the old environment is no longer accessible from the destination environment. If the old environment is accessible, when you spin up the config servers and mongos, they will attempt to reach out to the old shard servers. You will then see messages like this:
Secondly, the documentation assumes that you are restoring either onto the same source cluster, or onto a new cluster that has been configured identically - not onto a new blank cluster, or one with different hostnames. If you do try to do it onto a blank cluster, particularly one with different hostnames, you will hit some issues. Ideally, it would be nice if the most efficient way of doing this particular type of restore was also documented as well. |
| Comments |
| Comment by Emily Hall [ 27/Jul/16 ] |
|
Closed by Emily Hall for Housekeeping on 7/27/16. Thank you! |