[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:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  5
        Last reported error:  Could not find host matching read preference { mode: "primary" } for set rs0
 

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/
or
https://docs.mongodb.com/manual/tutorial/backup-sharded-cluster-with-database-dumps/

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

Generated at Thu Feb 08 04:40:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.