11

For scaling/failover mongodb uses a “replica set” where there is a primary and one or more secondary servers. Primary is used for writes. Secondaries are used for reads. This is pretty much master slave pattern used in SQL programming. If the primary goes down a secondary in the cluster of secondaries takes its place. So the issue of horizontally scaling and failover is taken care of. However, this is not a solution which allows for sharding it seems. A true shard holds only a portion of the entire data, so if the secondary in a replica set is shard how can it qualify as primary when it doesn’t have all of the data needed to service the requests ?

Wouldn't we have to have a replica set for each one of the shards?

This obviously a beginner question so a link that visually or otherwise illustrates how this is done would be helpful.

alex sundukovskiy
  • 483
  • 1
  • 7
  • 19
  • That shard will have the data needed to satisfy the requests sent to it, and yes you can have a replica per shard, here is a cookbook tutorial: http://cookbook.mongodb.org/operations/convert-replica-set-to-replicated-shard-cluster/ – Sammaye Feb 06 '13 at 21:39

3 Answers3

8

Your assumption is correct, each shard contains a separate replica set. When a write request comes in, MongoS finds the right shard for it based on the shard key, and the data is written to the Primary of the replica set contained in that shard. This results in write scaling, as a (well chosen) shard key should distribute writes over all your shards.

Alptigin Jalayr
  • 719
  • 4
  • 12
  • Thank you! Can it be done in the opposite way? Each server in a replica set cluster is sharded. Detailed description: Suppose we have a replica set. Great we got the ability to service more reads, we got failover. Now our issue is that the size of data on each server ( which I referred to as server) is getting rather large. So we shard the data on each server. Isn't that the opposite of what you described? Or is it that from implementation point of view it's all the same "thing"? – alex sundukovskiy Feb 07 '13 at 00:06
  • @alexsundukovskiy I am unsure what you mean but you cannot shard a replica set itself – Sammaye Feb 07 '13 at 08:18
  • @alexsundukovskiy Let's assume SHARD_KEY has possible values {A,B,C,D} and you have 2 shards. Each shard has replica set consisting of 3 machines. Now, theoretically, your documents should be uniformly distributed over your SHARD_KEY, i.e. number of documents arriving with SHARD_KEY = A, SHARD_KEY = B etc should be equal. Let's say this happy situation continues for a while. Then, one of 2 things starts happening: (contd below) – Alptigin Jalayr Feb 07 '13 at 15:05
  • 1) The overall number of documents starts getting huge, and all the shards start filling up. You can either: (a) Get bigger machines (b) Increase number of shards (for example) from 2 to 4. 2) Your initial assumptions on distribution of docs over SHARD_KEY were wrong, and only shard #1 starts filling up. In this case, you need to choose a new key or choose a compound key. The only way to migrate to the new key/compound key (AFAIK) is to dump all the data, create new collection based on the new key, and move it all back in. – Alptigin Jalayr Feb 07 '13 at 15:06
  • Thank you! Thanks for the explanation, now it makes sense why the designers made a decision to replicate shards as opposed to shard "replicates". – alex sundukovskiy Feb 08 '13 at 05:51
1

A shard is the sum of a primary and secondaries (replica set), so yes, you would have to have a replica set in each shard.

The portion of the entire data is held in the primary and it's shared with the secondaries to maintain consistency. If the primary goes out, a secondary is elected to be the new primary and has the same data as its predecessor to begin serving immediately. That means that the sharded data is still present and not lost.

Alderis Shyti
  • 278
  • 1
  • 8
  • 1
    A shard is a range of data of the sharded collection, a replica can exist without a shard and a shard can exist without a replica – Sammaye Feb 06 '13 at 23:15
  • @Sammaye I fail to understand how a replica set can exist on its own in a sharded environment. (could you mean that it doesn't have to be a shard in a non-sharded environment?) When we say "shard", don't we mean that the replica set is part of a bigger data scope? About the shard being able to exist without a replica set I agree though. But that was not the case he put through, thus I adjusted my answer to his scenario which involved replicas, not single units. – Alderis Shyti Feb 07 '13 at 00:11
  • Exactly the definition of shard is not always within a replicated environment, it sounded like the "definition" of a shard was to exist in a replica. I am still unsure what you mean by the "sum of a primary and secondaries" since if that were to be the case wouldn't the primary (the shard) have duplicate data. The secondaries are replicas of the primary, the shard, well kind of, depends upon replication there – Sammaye Feb 07 '13 at 08:10
  • @Sammaye Yeah, my explanation using "sum" might have been confusing there. I mostly meant the "sum" entity-wise but not data-wise because I wanted to counter what the person asking was saying that `if the secondary in a replica set is shard how can it qualify as primary`. The secondary is not the actual shard, the whole set is considered a shard but only one entity serves data. Thankfully, he sorted it out. – Alderis Shyti Feb 07 '13 at 08:31
  • Ok kool, yea that sounds ok :) – Sammaye Feb 07 '13 at 08:34
0

You would typically map individual shards to separate replica sets. See http://docs.mongodb.org/manual/core/sharded-clusters/ for an overview of MongoDB sharding.

epc
  • 334
  • 1
  • 5
  • Thank you, I wonder if it ever happens the other way around. In other words could we have each node in the replica set sharded? And if not what's wrong with doing that ? – alex sundukovskiy Feb 06 '13 at 23:26
  • I am not sure I understand your question. You shard collections within a database, and sharding runs on top of replica sets. MongoDB does not have a concept of sharding a node. You could certainly choose to shard all of the collections in all of your databases, however that's probably overkill depending on your workload. – epc Feb 06 '13 at 23:28
  • Suppose we have a replica set. Great we got the ability to service more reads, we got failover. Now our issue is that the size of data on each server ( which I referred to as node) is getting rather large. So we shard the data on each server. Isn't that the opposite of what you described? Or is it that from implementation point of view it's all the same "thing"? – alex sundukovskiy Feb 07 '13 at 00:03