0

I am using Mongo Sharded cluster with two shards.
There was an issue on my one shard and and it was down for around 30 minutes.
It stopped my writes to other shards also.
Logically if one shard is down other shard must be able to take part of writes but allow rites got failed in that duration.

Command failed with error 133: 'could not find host matching read preference { mode: "primary", tags: [ {} ] } for set firstset' on server xxxx . The full response is { "code" : 133, "ok" : 0.0, "errmsg" : "could not find host matching read preference { mode: \"primary\", tags: [ {} ] } for set firstset" }

Could you please help me why this happened.

Mongo version : 3.2.9 Shard Key contentID : alphanumeric value

https://docs.mongodb.com/manual/sharding/#high-availability

Thanks
Virendra Agarwal

  • What sort of shard key did you have for the affected collection(s)? Can you provide an example of a failing query or write operation? Also, what specific version of MongoDB server are you using? One possibility is that your operation was attempting to read/write from the downed shard rather being targeted to the available shards. For example, queries not using the shard key will return an error unless you set the option to allow partial results (generally not a useful outcome for most use cases). – Stennie Nov 27 '17 at 5:59
  • That might be possible as my query was not suing shard key. so i will use this partial query flag. But for write i am still concerned as most of the data was new as new content generated this time of day. – viren Nov 27 '17 at 6:09
  • Assuming your sharded collections have keys that evenly distributes writes, a downed shard is going to be problematic for 1 / n sharded writes if you have n shards. With only two shards that's 50% of your writes. For production deployments you generally want to avoid a fully unavailable shard - each shard should be backed by a replica set providing suitable fault tolerance for your requirements. Partial results and other steps are disaster mitigation; a shard fully down is not a healthy deployment. – Stennie Nov 27 '17 at 22:54
0

You have understood concept cluster and sharding wrong or you are mixing it with ideas of replica set. If cluster misses part of it (shard(s)), it is not whole and cannot function.

Replica set can function when minority of nodes are missing and that's why (sharded) cluster is normally made from replica sets. So, that every shard in the cluster is replica set, at least three nodes. So, in two shard cluster, you have actually six data nodes (2x3) and top of that you have three node config server replica set.

  • I have added link where it is mentioned that part of sharded cluster will be functional logically i should not be able to access the data on unavailable shard but other parts should work. – viren Nov 27 '17 at 4:46
  • 1
    Yes, you are of course right... But only with very strict sharding key circumstances, so that every read and write goes ONLY those shards what are still up. With writes this is more or less hard to archive because writes should be distributed evenly to all shards and not only one (that is called "hot spot"). – JJussi Nov 27 '17 at 6:59

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.