Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.
Sign up to join this community
I am a newbie to mongodb.I have set an mongodb architecture with a single mongo shard(mongos) connected to three shards(replica sets) with three config servers. The architecture looks as below:
Now the mongos are connected with these shards.The data in the mongos will be splitted among these three shards.What is my doubt is whether the shard 1 contains the same exact data as that of shard 2 and shard 3 or all the 3 shards have different data.
So let's look at the "roles" here represented in the referenced architecture. Keep in mind, this is the "2 cent tour" of what the architecture is all about.
This process is the "router" in that it acts as the interface for a "client" to connect to a sharded cluster. You can have many mongos instances, so you are not limited to "one" only. As pointed to in the diagram, these communicate with the "config servers" in order to determine which "shard" to send requests to based on the query or operation submitted.
These are the "brains" of a sharded cluster. Essentially they contain the "meta data" which says which "chunks" or "parts of the data" appear on which "shard" as it were. These stay consistent with each other in a "reasonably redundant way" in order to provide that information to the mongos "router".
Mostly a "meta" concept here. Though it is possible have a single server as a "shard" it is generally recommended not to and to use a "replica set" as a shard node otherwise. The purpose of a "shard" is to hold data "specific" to a "defined range". This works by a "shard key" that is "split" between "nodes" of the sharded cluster. The full nature of the "splitting" is determined by the "shard configuration" which lives on the "config servers" already described. The data on a "shard" only lives on that shard and "no-where else".
The purpose of a replica set is rather self explanatory. It essentially "copies" data from a given "Primary" node which is the only node that accepts "write" operations. This is done to what is one or more "Secondary" nodes. You only need one more "Secondary node for a replica set, but if you do that then you really need another "Arbiter" node in order to break the deadlock on elections.
What "elections" means is that when one member of the replica set goes down or is otherwise un-available, there is an "election" held to determine which one then becomes the new "Primary". There needs to be a "majority" vote here, hence the requirement for an "odd number" of members that can vote (not all member types can vote).
There is no "duplication" over shards. There may be a "brief" time in which the same data appears on one shard and another at the same time, but this is never reflected in the "config servers" ( if it is then this is corruption ). There is a process called "chunk migration" which is what all of this is about, where data allocated to one shard is "balanced" to exist on another. But the "meta data" mentioned earlier is "atomically updated" so there should be a consistent view of where the true source of data actually resides.
The "replica set" members are where there is intentional duplication. This is for data redundancy, where if one member goes down then there are other members to carry on the work. They "should" have a consistent view, but this generally is largely determined by "write concern" in your application as to the "guarantee" of consistency. Still, there may be problems if only rare. (But network partitions in the cloud happen more often than not).
The role of "shards" is opposite to the "redunancy" of replica sets. Their role is to "distribute" data. That means by definition that data is not "duplicated" over shards (moment case already given) so that general CRUD operations are either "distributed" or "targeted", across or directed to as appropriate the relevant "shard" that is going to deal with the data for your operation.
In real short. Shards are for "data distribution" in order to make operations scalable, by either "targeting" workload to a specific "shard node" or "splitting" the workload across many nodes. Whatever is appropriate to your application purpose.
Always different data across shard nodes, and that is what they exist for.
