Database Reference
In-Depth Information
9.1.2
How sharding works
To u n d e r s t a n d h o w M o n g o D B 's sh a r d in g w or ks , y o u ne e d t o k n o w a b o ut t h e c o m p o -
nents that make up a sharded cluster, and you need to understand the software pro-
cesses that coordinate those components. These are the subjects of the next two
sections.
S
HARDING
COMPONENTS
A sharded cluster consists of shards,
mongos
routers, and config servers. Refer to the
diagram in figure 9.1 as we discuss each of these components.
Shards
A MongoDB shard cluster distributes data across one or more shards. Each shard is
deployed as a MongoDB replica set, and this set stores some portion of the cluster's
total data. Because each shard is a replica set, each shard has its own replication mech-
anism and can fail over automatically. You can connect directly to an individual shard
just as you would to a standalone replica set. But if you connect to a replica set that's
part of a sharded cluster, you'll see just a portion of the cluster's total data.
Mongos routers
If each shard contains part of the cluster's data, then you still need an interface to the
cluster as a whole. That's where
mongos
comes in. The
mongos
process is a router that
directs all reads and writes to the appropriate shard. In this way,
mongos
provides cli-
ents with a coherent view of the system.
mongos
processes are lightweight and nonpersistent. They typically reside on the
same machines as the application servers, ensuring that only one network hop is
g
server
g
server
Shard A
(replica set)
Shard B
(replica set)
g
server
Two-phase commits
Metadata
mongos router
(in-memory copy
g data)
Reads and writes
Application
Figure 9.1
Components in a
MongoDB shard cluster
