MongoDB DBA Associate common mistakes
MongoDB DBA Associate · Understand the traps and how to avoid them.
Treating a replica set member's election priority and its votes as the same setting, so a candidate assumes a high-priority secondary can win an election it has no vote for, or that a zero-priority member cannot vote.
Both live in rs.conf() member documents and both affect elections, so candidates conflate the two; they forget that priority controls electability (who can become primary) while votes control participation in the election quorum, and that a member with priority 0 is still electable only if all higher-priority members are unavailable.
What to do instead
Memorize the separation: priority (0 = never primary under normal conditions, higher wins ties broken by freshness) versus votes (0 or 1, majority of voting members needed to elect). Practice reading an rs.conf() and predicting the outcome when the current primary fails, including the case where votes total is even and a majority is therefore harder to reach.
Assuming writes survive a failover as soon as they are acknowledged with default write concern, then being surprised when a rolled-back document disappears after the old primary rejoins.
Default w:1 acknowledges on the primary only; on failover, uncommitted writes that had not replicated to a majority can be rolled back. Candidates memorize the write concern levels but do not connect them to the rollback window and the journaling behavior of j:true.
What to do instead
State the rule explicitly when answering: durability across failover requires a majority write concern (w:"majority"), optionally with j:true for on-disk durability before acknowledgment. Be able to explain what happens to a w:1 write when the primary dies before replication, and how to inspect rollback files after the fact.
Choosing a shard key by intuition (for example, a timestamp or a monotonically increasing ID) and then claiming the cluster will scale writes, without checking cardinality or frequency.
Low-cardinality or monotonically increasing keys are the classic textbook trap, and candidates recognize the words but do not apply the test: does the key have high cardinality, low frequency, and support the dominant query pattern? A monotonic key sends all inserts to one chunk on one shard.
What to do instead
Before answering, run the three checks out loud: cardinality (enough distinct values to split), frequency (no single value dominating), and monotonicity (avoid ever-increasing values unless hashed). Then connect the key to the query pattern, since a hashed key fixes write distribution but breaks range-targeted reads.
Describing the balancer as moving individual documents between shards, or as running continuously on every mongos.
The mental model of sharding is often fuzzy at the chunk level; candidates skip the fact that the balancer moves chunks, runs on the primary of the config server replica set, and is a background process that can be stopped or scheduled.
What to do instead
Anchor the architecture: config server replica set holds chunk metadata, mongos caches and routes, shards hold data. The balancer migrates chunks, is controlled via sh.startBalancer()/sh.stopBalancer() and the balancer window, and runs from the config server primary. Be able to explain what happens to in-flight migrations when the balancer is stopped (they finish, new ones do not start).
Assuming enabling authentication (security.authorization: enabled) also forces clients to authenticate, or that creating a user in the admin database grants cluster-wide privileges automatically.
Authentication and authorization are separate settings, and role-based privileges are scoped to the database where the role is granted unless a cluster-wide role (such as clusterAdmin or root) is used. Candidates also forget the localhost exception for bootstrapping the first user.
What to do instead
Separate the two switches: authorization enabled turns on role checks; authentication mechanisms (SCRAM, x.509, LDAP, Kerberos) determine how identity is proven. Remember the localhost exception applies only when no users exist, and that built-in roles are per-database unless they are cluster-scoped.
Believing enabling TLS on mongod is sufficient, without accounting for internal member-to-member authentication and the client-side certificate requirements.
TLS configuration has several interacting options (mode, certificateKeyFile, CAFile, allowConnectionsWithoutCertificates, clusterAuthMode), and candidates memorize one flag without the deployment-wide picture, including that internal x.509 authentication uses the same certificates.
What to do instead
Map the modes: disabled, allowTLS, preferTLS, requireTLS, and how clusterAuthMode interacts for internal auth. Know that a replica set or sharded cluster needs consistent CA trust across all members, that hostnames in certificates must match the names members use to connect, and that clients need the CA to verify the server.
Planning backups around filesystem copies of the dbPath while mongod is running, or treating mongodump as a consistent point-in-time snapshot of a sharded cluster by default.
Candidates learn mongodump as "the backup tool" and stop there; they miss that a live file copy is unsafe without journal/fsync coordination, and that mongodump against a sharded cluster does not give a cluster-wide consistent snapshot without stopping the balancer and writes.
What to do instead
Match tool to scenario: mongodump/mongorestore for logical export and selective restore; filesystem snapshots with fsyncLock or a journal-consistent volume snapshot for physical backups; Ops Manager/Cloud Manager for continuous, point-in-time backup of replica sets and sharded clusters. For sharded logical backups, stop the balancer and pause writes, or accept per-shard consistency only.
Reading db.serverStatus() or mongostat and concluding the database is the bottleneck, without checking whether the observed latency is queueing on locks, disk, or the storage engine's cache.
Candidates jump from a high operation count or slow query to "add an index," skipping the diagnostic ladder: is it CPU, memory pressure, disk I/O, lock contention, or a missing index? WiredTiger cache eviction and checkpoint behavior are frequently ignored.
What to do instead
Use a fixed sequence: check serverStatus for connections, opcounters, and wiredTiger cache (bytes currently in cache versus maximum), check currentOp and the profiler for slow operations, check mongotop/mongostat for collection-level and per-second behavior, and only then decide whether the fix is an index, more cache, or more I/O. Name the specific metric you would look at for each hypothesis.
Describing an upgrade as "install the new binaries and restart," without ordering the steps for replica sets and sharded clusters or accounting for featureCompatibilityVersion.
The upgrade path has strict ordering (secondaries first, then step down the primary, then upgrade it; config servers and mongos in a defined order for sharded clusters), and FCV gates which features are available. Candidates memorize the version numbers but not the sequence.
What to do instead
Recite the replica set order: upgrade all secondaries one at a time, step down the primary, upgrade the former primary, then raise featureCompatibilityVersion only after all members run the new version. For sharded clusters, upgrade config servers, then shards, then mongos, and keep the balancer considerations in mind. Know that FCV can be lowered only within supported limits.
Using mongosh as a thin SQL-like shell and being unable to write a query that filters, projects, sorts, and explains a plan, or misusing mongorestore --drop and --nsFrom/--nsInclude.
The tools domain rewards practical fluency, and candidates often know the commands exist but not their semantics: --drop deletes existing collections before restore, namespace remapping uses specific flag syntax, and explain("executionStats") is needed to see documents examined versus returned.
What to do instead
Practice a small set of concrete operations: a find with filter, projection, sort, and limit; explain("executionStats") to compare keysExamined with docsExamined; mongodump with --gzip and --archive; mongorestore with --nsFrom/--nsTo for renaming and --dryRun to preview. Be able to say exactly what --drop does to data not present in the dump.