[SERVER-35718] Facing issue with sharded cluster restore on different server. Created: 06/May/18 Updated: 05/Feb/20 Resolved: 06/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.6.3 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Minor - P4 |
| Reporter: | Nitin | Assignee: | Nick Brewer |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Sharded cluster with 2 shards 3 replica set each and config server replica set. One mongos process. All on same server (Linux x86_64) |
||
| Participants: |
| Description |
|
I am trying to restore mongodb sharded cluster deployment from one server to another . Current deployment has 2 shards, 3 replica each and config server replica set .one mongos process. Took backup from primary shards and config server primary . used fsynclock for same. moved the backup to different server . Created new deployment with same replica set name on different ports that the source. Restored shards and then config server . updated config database shards collection with new server details but deployment is not getting started after the restore . getting below error in sh.status. balancer: Have tried several times the redirected restore using the link: https://docs.mongodb.com/manual/tutorial/restore-sharded-cluster/ but with no luck .
|
| Comments |
| Comment by Nick Brewer [ 21/Jun/18 ] |
|
mukhejan Can you be more specific as to the steps that you're taking to back up the server, and the actions you're taking to modify it once it's brought back up? The backup process for a sharded cluster (whether using database dumps or filesystem snapshots) involves stopping the balancer, locking secondary replica set members, and then taking a backup of one replica set member for each shard. Are you using the backup process outlined in our documentation? Specifically: https://docs.mongodb.com/manual/tutorial/backup-sharded-cluster-with-filesystem-snapshots/ It'd be useful to get a sense of what the cluster configuration looks like before and after the move - specifically output of rs.conf() and sh.status() on both the original and restored cluster, as well as any logs from the restored mongod machines, when they're first brought up. If you'd prefer, you can use our secure upload portal to provide this information. This is only available to MongoDB employees, and the information provided is automatically removed after a period of time. Regards, Nick |