Troubleshooting Scenario Questions

Convert the secondary to an arbiter to reduce its workload.

Why it fails: An arbiter does not store data and cannot replicate or serve reads. Converting a lagging secondary to an arbiter would remove a data-bearing member, reducing redundancy and read capacity. It does not help with replication lag because the arbiter does not apply oplog entries. This would worsen the situation by eliminating a replica.

Increase the write concern on the primary to ensure the secondary acknowledges writes.

Why it fails: Increasing write concern to require acknowledgment from the secondary would slow down the primary's write throughput and could increase lag if the secondary is already struggling. Write concern controls durability guarantees, not replication speed. It does not help the secondary apply oplog entries faster and may exacerbate the problem by adding latency.

Increase the size of the oplog on the primary and secondaries.

Why it fails: Increasing the oplog size extends the oplog window, which helps prevent the secondary from falling off the oplog and requiring a full resync. However, it does not address the root cause of the lag, which is likely insufficient write capacity or network throughput on the secondary. A larger oplog is a mitigation, not a solution to reduce lag.

Add a hint forcing the query to use the _id index.

Why it fails: The _id index only supports lookups by _id. Forcing it with hint on an equality-plus-range query against other fields causes a full index scan of _id entries followed by document fetches and in-memory filtering, which increases work rather than reducing documents examined. It is a misapplication of hint for this predicate shape.

Set the query's read concern to 'majority' to reduce examined documents.

Why it fails: Read concern controls the consistency and durability guarantees of the data returned, not the access path or the number of documents examined. Setting majority read concern can actually add latency because it waits for replicated acknowledgement. It has no effect on how many keys or documents the query plan inspects.

Increase the index's fill factor using collMod to leave more space on pages.

Why it fails: MongoDB's WiredTiger storage engine does not expose a fill factor setting for indexes in the way some relational systems do, and collMod does not tune index page fill. Even if it did, page packing affects write and split behavior, not the number of index keys or documents a query must examine for a given predicate.

The config servers are in a read-only state.

Why it fails: If the config servers were read-only, the entire cluster would be unable to perform metadata updates, and the balancer would be unable to function. However, the scenario states the balancer state is `true`, implying the balancer is enabled. A read-only config server would likely cause broader failures, not just prevent migrations while the balancer appears active.

The collection has no indexes on the shard key, so the balancer cannot identify chunks to migrate.

Why it fails: MongoDB automatically creates an index on the shard key when a collection is sharded. The balancer operates on chunk metadata stored in the config servers, not on indexes. Missing indexes would affect query performance, not the balancer's ability to migrate chunks.

The shard key is hashed, and hashed shard keys prevent the balancer from migrating chunks.

Why it fails: Hashed shard keys do not prevent the balancer from migrating chunks. In fact, hashed sharding is designed to distribute data evenly, and the balancer works with hashed chunks just like ranged chunks. The balancer migrates chunks based on chunk counts, regardless of the shard key type.

db.runCommand({balancerStop: 1}) on the admin database

Why it fails: The balancerStop command is the underlying command that sh.stopBalancer() wraps, but it must be run against the admin database. Running it from a non-admin database will fail. Additionally, using the helper sh.stopBalancer() is the standard and recommended approach, as it handles the admin database context automatically.

sh.disableBalancer()

Why it fails: sh.disableBalancer() is not a valid MongoDB shell helper. The correct method is sh.stopBalancer(). There is no disableBalancer method in the sh namespace. Using an invalid command will result in an error and will not stop the balancer.

sh.setBalancerState(false)

Why it fails: While sh.setBalancerState(false) does disable the balancer, it is a lower-level command that may not wait for in-progress migrations to complete. sh.stopBalancer() is preferred because it also waits for the balancer to stop any current migrations before returning. Using setBalancerState(false) could leave migrations running, which might not fully address the performance issue.

Restart the secondary to see if the lag clears.

Why it fails: Restarting the secondary is a disruptive action that should not be the first step. It may temporarily resolve issues but does not diagnose the root cause. It could also cause further lag if the secondary needs to resync. Diagnosis should begin with monitoring commands like rs.printSlaveReplicationInfo().

Run db.currentOp() on the secondary to see long-running operations.

Why it fails: db.currentOp() can show long-running operations on the secondary, but replication lag is typically caused by the secondary applying oplog entries, not by user queries. While it might reveal an issue, the first step should be to quantify the lag and check the oplog progress using rs.printSlaveReplicationInfo().

Increase the oplog size on the primary to allow more time for the secondary to catch up.

Why it fails: Increasing the oplog size does not address the secondary's inability to keep up; it only provides a larger window for the secondary to catch up if it falls behind. It does not diagnose or fix the underlying performance issue on the secondary. The first step should be to understand why the secondary is lagging.