1

Well as I understand each database has it's primary shard, which is mostly the first shard added to mongodb cluster. And we know that balancer will not split chunks until the chunksize is bigger than the half of the max chunk size, so the balancer will not move any data to the specified shards, for example when we use tag aware sharding. So I wonder what will happen when the primary shard is down?

Thanks a lot.

Improve this question

2 Answers 2

Reset to default
2

The primary shard

The term primary shard refers to the shard of a cluster on which the non-sharded collections of a database are located. This can can (and in the case that you only had one shard when creating a database will) be the first shard added to a cluster. But if you have multiple shards, any of those may be selected as the primary shard for new databases.

What happens if the primary shard fails

Ok, let's assume you only have standalone servers as shards. If the primary fails, all unsharded collections residing on that shard become unavailable. Additionally, all chunks residing on that shard become unavailable, too. Another effect is that writing documents with shard keys currently associated with the failed shard becomes impossible.

With reads and writes from and to the failed shard being impossible, there is a more subtle effect caused: chunk migrations from and to said shard can't be executed. This may lead to jumbo chunks, which have to be identified and then split manually before they can be migrated by the balancer.

Conclusion

All of the above makes it very clear why a shard should be a replica set and not a standalone server, except when using MongoDB for caching purposes (maybe).

Additional info

If the primary replica set member of a shard goes down, elections will be held, the new primary will be announced and everything (except for the failed machine) is back to normal. Even on heavily loaded clusters I haven't seen Jumbo chunks because of a failover, yet.

Improve this answer
4
  • Jumbo chunks are created by low cardinality shard key values or as a side effect of the cluster metadata being read-only (i.e. when one or more config servers are unavailable). If all servers for a shard are unavailable, that doesn't lead to jumbo chunks on other shards. Chunk splits are still possible as they only affect metadata on the config servers; chunk migrations or any interaction to/from the downed shard will continue to be attempted but fail. Would definitely recommend always using replica sets in production (with or without sharding) for fault tolerance and admin flexibility.
    – Stennie
    Commented Sep 7, 2015 at 10:19
  • @Stennie : Hmm, I think you are right, but wasn't there something that if a chunk is scheduled for migration it can't be split until the chunk migration is finished? Since the chunk will not be successfully migrated (but still is scheduled to be), documents may be added to said chunk until it is jumbo, right?
    – Markus W Mahlberg
    Commented Sep 7, 2015 at 10:33
  • A chunk is metadata representing a contiguous range of shard key values. Chunk splits are metadata updates when data is inserted/updated into a shard; migrations involve moving documents between shards. If the migration process selects a chunk larger than the configured chunk size it will attempt to split the chunk before migration. Failure to split a chunk will result in it being flagged as a jumbo chunk but doesn't depend on target shard availability.
    – Stennie
    Commented Sep 7, 2015 at 11:00
  • Stennie, I am pretty aware of what a chunk is. What I described was a bit away from the textbook. Again: When a chunk is queued for migration, documents can still be added. But a chunk queued for migration will not be splitted until it is migrated, will it? I find the docs to be a bit unclear on that. If it won't be split until the migration is finished and the target shard becomes unavailable (meaning that the migration simply can't be finished), my assertion is that this chunk can turn into a jumbo chunk since it will not be split although it can grow.
    – Markus W Mahlberg
    Commented Sep 7, 2015 at 12:41
2

I guess you mean primary shard is down, because the term primary database is not applicable. The behavior will be the same as losing any other shard. The difference is that both sharded and unsharded collections will get affected.

Improve this answer
2
  • I didn't say "primary database". The thing is, that when a database has a primary shard which is down, then what will happen to collections that are about to be moved to another shard by tag aware sharding for example is not clear.
    – Edik Mkoyan
    Commented Sep 7, 2015 at 10:01
  • 1
    Yes you did, i changed the "primary database" into "primary shard" on your question. Collections can't be moved unless are sharded so i don't really understand your question. Also tag-aware sharding is not on your initial question.
    – Antonios
    Commented Sep 7, 2015 at 11:16

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.