I85PREP
⌘ K
MongoDB DBA Associate study materials
MongoDB DBA Associate study resources

MongoDB DBA Associate: Deployment, Installation, and Topology Planning

MongoDB DBA Associate · Work through your exam, one topic at a time.

All guide sections

Deployment, Installation, and Topology Planning

What this domain covers

The Deployment, Installation, and Topology Planning domain tests whether you can select a production topology, prepare hosts, install MongoDB correctly, and configure mongod and mongos for reliability. Questions often ask you to choose between a replica set and a sharded cluster, identify required configuration file settings, and recognize OS-level tuning that affects stability.

Core rules

  • A production replica set needs at least three data-bearing voting members, ideally in three failure domains. Use an arbiter only to break a tie in an even-member set; arbiters hold no data and cannot become primary.
  • A sharded cluster requires mongos routers, a config server replica set (CSRS), and shard replica sets. Since MongoDB 3.6 the config servers must run as a replica set, not as three standalone SCCC servers.
  • Install from the official repository, tarball, or a supported container image. Pin the minor version and use the same version across all members during initial deployment.
  • In mongod.conf, set storage.dbPath, systemLog.path, net.port, net.bindIp, and security.authorization. The default bindIp is 127.0.0.1, which prevents remote connections.
  • Tune the host: disable transparent huge pages, set ulimits for open files and processes, use NTP, and choose XFS or ext4. Keep data, journal, and logs on separate volumes when possible.

Worked example

You plan a 500 GB data set on a 32 GB RAM host. WiredTiger cache is about 50% of (RAM minus 1 GB), so 15 GB. With compression, plan disk for at least the uncompressed working set plus index growth. Choose three data-bearing members across three availability zones, priorities 2/1/1, no arbiter. An arbiter would add a vote but no data redundancy and would prevent a data-bearing member from being added later without reconfiguring.

Traps

Assuming an arbiter improves durability; leaving bindIp at localhost; running mongod as root; using an even number of voting members without a tie-breaker; and forgetting that mongos stores no data.