Database Reference
In-Depth Information
given the critical role played by the config servers, some users prefer to place them on
a few modestly provisioned machines (or virtual instances).
From what you already know about replica sets and shard clusters, you can con-
struct a list of minimum deployment requirements:
Each member of a replica set, whether it's a complete replica or an arbiter,
needs to live on a distinct machine.
1
Every replicating replica set member needs its own machine.
2
Replica set arbiters are lightweight enough to share a machine with another
process.
3
Config servers can optionally share a machine. The only hard requirement is
that all config servers in the config cluster reside on distinct machines.
4
Satisfying these rules might feel like tackling a logic problem. Fortunately, we'll apply
them right now by looking at two reasonable deployment topologies for the sample
two-shard cluster. The first requires just four machines. The process layout is illus-
trated in figure 9.4.
This configuration satisfies all the deployment rules just mentioned. Predominant
on each machine are the replicating nodes of each shard. The remaining processes
are arranged so that all three config servers and all members of each replica set live
on different machines. To speak of fault tolerance, this topology will tolerate the fail-
ure of any one machine. No matter which machine fails, the cluster will continue to
process reads and writes. If the failing machine happens to host one of the config
Shard A
mongod
(27017)
Shard A
mongod
(27017)
Shard B
arbiter
(30000)
Config
Config
server
(27019)
server
(27019)
Machine 2
Machine 1
Shard B
mongod
(27017)
Shard B
mongod
(27017)
Config
Shard A
arbiter
(30000)
server
(27019)
Figure 9.4
A two-shard
cluster deployed across
four machines
Machine 3
Machine 4
