Troubleshooting practice questions

A DBA is troubleshooting a replica set where the secondary is consistently lagging behind the primary by several hours. The DBA notices that the secondary's optime is far behind the primary's optime, and the secondary's oplog window is only 1 hour. The primary has a heavy write workload. Which action should the DBA take to reduce the replication lag and prevent the secondary from falling off the oplog?

Trap 1: Convert the secondary to an arbiter to reduce its workload.

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.

Trap 2: Increase the write concern on the primary to ensure the secondary…

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.

Trap 3: Increase the size of the oplog on the primary and secondaries.

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.

A
Scale the secondary vertically by adding more CPU, RAM, or faster disk I/O.
Replication lag often occurs when the secondary cannot apply oplog entries as fast as the primary generates them. Upgrading the secondary's hardware—especially faster disks and more CPU—can increase its oplog application rate, reducing lag. This addresses the underlying performance bottleneck and is the most direct way to improve replication throughput.
B
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.
C
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.
D
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.

Question 2mediummulti select

A DBA is troubleshooting a slow query on a large collection. Which two techniques directly reduce the number of documents the query must examine for an equality-plus-range predicate? (Choose two.)

Trap 1: Add a hint forcing the query to use the _id index.

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.

Trap 2: Set the query's read concern to 'majority' to reduce examined…

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.

Trap 3: Increase the index's fill factor using collMod to leave more space…

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.

A
Create a compound index with the equality field first and the range field second.
Placing the equality field first gives the index a tight prefix bound, and the range field second allows the index to scan only the relevant range within that equality. This ordering lets the engine seek directly to matching keys rather than scanning broadly, directly cutting documents examined. It is a core index design rule for mixed equality and range predicates.
B
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.
C
Create a partial index with a filter expression matching the query's equality predicate.
A partial index stores entries only for documents satisfying its filter expression, so when the filter matches the query's equality predicate, the index is smaller and the planner can seek to exactly those entries. This reduces keys and documents examined compared to a full index, and lowers storage and write overhead. It is a valid technique for shrinking the working set.
D
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.
E
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.

Question 3hardmultiple choice

A DBA is troubleshooting a sharded cluster where the balancer is not migrating chunks even though there is an imbalance. The DBA runs `sh.getBalancerState()` and it returns `true`. Which of the following is the most likely reason the balancer is not migrating chunks?

Trap 1: The config servers are in a read-only state.

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.

Trap 2: The collection has no indexes on the shard key, so the balancer…

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.

Trap 3: The shard key is hashed, and hashed shard keys prevent the balancer…

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.

A
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.
B
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.
C
The balancer window is configured to a time period outside of the current time.
Even if the balancer is enabled, it only runs during the configured balancing window. If the window is set to a time outside the current time, no migrations will occur. The DBA should check `sh.getBalancerWindow()` to see the active window and adjust it if necessary.
D
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.

Question 4hardmultiple choice

Refer to the exhibit. An administrator inspects chunk metadata for a sharded collection using a compound shard key: { region: 1, account_id: 1 }. What does the presence of MinKey and MaxKey signify in this specific chunk range definition?

Exhibit

{
  "ns": "finance.accounts",
  "min": { "region": "EMEA", "account_id": MinKey },
  "max": { "region": "EMEA", "account_id": MaxKey },
  "shard": "shard01"
}

Trap 1: They indicate that the chunk is corrupted and requires immediate…

They indicate that the chunk is corrupted and requires immediate repair using the validate command on the config server. MinKey and MaxKey are standard internal BSON types utilized by MongoDB to define open-ended or bounded compound chunk ranges without indicating any form of data corruption.

Trap 2: They specify encryption keys used by the WiredTiger storage engine…

They specify encryption keys used by the WiredTiger storage engine to secure data chunks at rest on shard01. Storage encryption keys are managed separately through KMIP or local key files and have no relationship to chunk boundary definitions or BSON range keys.

Trap 3: They are temporary placeholder values assigned by the balancer…

They are temporary placeholder values assigned by the balancer during active chunk splits that will automatically expire after twenty-four hours. MinKey and MaxKey remain permanently embedded as boundary markers in chunk metadata to define valid sort and range limits indefinitely.

A
They represent absolute lower and upper bounds for the account_id field within the EMEA region, ensuring all accounts for that region reside in this chunk.
They represent absolute lower and upper bounds for the account_id field within the EMEA region, ensuring all accounts for that region reside in this chunk. MinKey and MaxKey act as universal wildcards for the trailing compound fields, capturing all possible account identifiers associated with the EMEA region inside shard01.
B
They indicate that the chunk is corrupted and requires immediate repair using the validate command on the config server.
Why it fails: They indicate that the chunk is corrupted and requires immediate repair using the validate command on the config server. MinKey and MaxKey are standard internal BSON types utilized by MongoDB to define open-ended or bounded compound chunk ranges without indicating any form of data corruption.
C
They specify encryption keys used by the WiredTiger storage engine to secure data chunks at rest on shard01.
Why it fails: They specify encryption keys used by the WiredTiger storage engine to secure data chunks at rest on shard01. Storage encryption keys are managed separately through KMIP or local key files and have no relationship to chunk boundary definitions or BSON range keys.
D
They are temporary placeholder values assigned by the balancer during active chunk splits that will automatically expire after twenty-four hours.
Why it fails: They are temporary placeholder values assigned by the balancer during active chunk splits that will automatically expire after twenty-four hours. MinKey and MaxKey remain permanently embedded as boundary markers in chunk metadata to define valid sort and range limits indefinitely.

Question 5mediummultiple choice

When evaluating the performance of a 'hint' in MongoDB, what should you keep in mind?

Trap 1: Hints are always faster than the optimizer's choice.

The optimizer is designed to calculate the most efficient path based on statistics. Forcing an index via a hint often leads to slower queries if the data changes and the index is no longer the most efficient option for the new distribution, resulting in suboptimal performance.

Trap 2: Hints should be used for all production queries.

Using hints for all production queries is a significant anti-pattern. It makes the application rigid and prevents MongoDB from automatically optimizing query execution as data grows or schema changes. It creates a maintenance nightmare, as every index modification would require updating all the hardcoded query hints.

Trap 3: Hints are only available for aggregation queries.

Hints can be applied to both simple find() queries and complex aggregation pipelines. They are a universal tool for forcing execution plans across different query types, although they should be used sparingly and only after careful cost-benefit analysis and thorough testing in a production-like environment.

A
Hints are always faster than the optimizer's choice.
Why it fails: The optimizer is designed to calculate the most efficient path based on statistics. Forcing an index via a hint often leads to slower queries if the data changes and the index is no longer the most efficient option for the new distribution, resulting in suboptimal performance.
B
Hints should be used for all production queries.
Why it fails: Using hints for all production queries is a significant anti-pattern. It makes the application rigid and prevents MongoDB from automatically optimizing query execution as data grows or schema changes. It creates a maintenance nightmare, as every index modification would require updating all the hardcoded query hints.
C
Hints prevent the optimizer from adapting.
A hint overrides the query optimizer, forcing it to use a specific index regardless of cost. This prevents the system from choosing better plans as the data distribution changes. This can result in performance regression as the application scales and the original index choice is no longer optimal.
D
Hints are only available for aggregation queries.
Why it fails: Hints can be applied to both simple find() queries and complex aggregation pipelines. They are a universal tool for forcing execution plans across different query types, although they should be used sparingly and only after careful cost-benefit analysis and thorough testing in a production-like environment.