2

I have set up a mongo cluster as follows:

  • Four shards => mongoshard1 (Disk1), mongoshard2 (Disk2), mongoshard3(Disk3), mongoshard4(Disk4)
  • Replica set of one configuration server => mongoshardconfig (Disk5)
  • One mongos server => mongos
  • Shard key is a hashed index of _id

The entire setup is on a single server and the various mongod instances have been setup on different ports. (Setting up on a single server instead of different nodes has been a conscious decision though against recommended practices)

My server got terminated and I created a new cluster on another server with exact same settings as above using the old disks. The sharded collection document has a field: url . For a particular id, if I search using _id, mongos returns null but returns the object on finding using the url. Connecting individually to shard2 returns the object on querying using same _id. Some of the documents are found by querying on _id through mongos and some are not.

Why is mongos unable to find the document using id? Can this be fixed?

0

When querying with _id thru mongos, system directs that query to right node using config -databases chunks -collection information. It sounds like that "order" of your shards has been changed. (meaning that disk1 is not anymore at mongoshard1 -machine). Connect shard directly and

use local db.me.find()

to check that nodes are who they should be.

  • That exactly was the problem. Correcting the order solved the problem for us. Thank you! – ankshah Jul 7 '17 at 6:28
  • Is there an alternative for the recovery process other than the way mentioned in the question? – ankshah Jul 7 '17 at 6:31
  • Moving all chunks to one shard (and then let balancer 're-balance' data back to other shards OR Dumping all data out, re-creating cluster and import data back. – JJussi Jul 7 '17 at 6:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.