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

Improve this question
3
  • 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
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 at 22:54

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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