Application Administration practice questions

Disable the oplog on the secondary members to remove replication overhead.

Why it fails: Disabling the oplog is impossible as it is a fundamental component of the replica set architecture required for replication and recovery. Removing it would break the cluster and prevent data synchronization between members, making high availability impossible for your production application environment.

Use an unacknowledged write concern (w: 0) for all application operations.

Why it fails: Using w: 0 provides no error feedback to the application if a write fails, leading to potential data loss without notification. While it offers the highest performance, it is risky for application integrity and prevents the driver from catching duplicate key errors or connectivity issues.

Increase the number of secondary nodes to distribute the write load.

Why it fails: Adding secondary nodes does not increase write capacity because all writes must still be directed to the primary node. Increasing the number of replicas actually increases the replication load on the primary, potentially decreasing write throughput rather than improving it in a standard configuration.

Use the .toArray() method on every query result to ensure data is accessible.

Why it fails: The .toArray() method loads the entire result set into the application's RAM at once. For large collections, this will likely lead to an OutOfMemory error on the application server, making it a poor choice for high-volume data retrieval tasks.

Increase the batch size to the maximum allowed by the driver.

Why it fails: Increasing the batch size to the maximum will cause a sudden spike in memory consumption on both the database server and the application server. This negates the benefits of batching and increases the risk of performance degradation or system crashes during high-traffic periods.

Store the result set in a global variable for reuse by other threads.

Why it fails: Storing large result sets in global variables creates memory leaks and concurrency issues. Since MongoDB cursors are ephemeral and tied to a session, global storage leads to stale data and prevents effective garbage collection, ultimately destabilizing the application's performance and stability.

The database is running out of memory for the sort operation.

Why it fails: While memory limits can cause issues with blocking sorts, the query would still attempt to use the index for filtering if possible. The execution plan showing a collection scan implies the index was not considered suitable for the query structure in the first place.

The 'status' field contains too many duplicate values.

Why it fails: Index selectivity affects performance, but it does not cause a query to ignore a valid index entirely. MongoDB's query optimizer evaluates available indexes based on filter and sort requirements, not purely on the cardinality of the values contained within the indexed field.

The explain('executionStats') method is slowing down the query.

Why it fails: The explain method provides diagnostic information and does not alter the execution strategy of the query. It is a reporting tool used for analysis and has no impact on whether the query engine chooses to use an index or perform a scan.

Manually restart the application every time a node fails.

Why it fails: If the application requires a manual restart, it defeats the purpose of high availability. A properly configured replica set and connection string should handle failover transparently, allowing the application to recover automatically without human intervention or downtime.

Increase the read preference to 'secondary' for all operations.

Why it fails: Setting the read preference to 'secondary' globally can lead to stale reads, which might break application logic that expects immediate consistency. Read preference should be chosen based on the specific business requirements of each query, not as a general configuration change for the cluster.

The index is not 'unique'.

Why it fails: Unique indexes are for data integrity, not performance. A non-unique compound index is perfectly capable of accelerating read queries. The lack of uniqueness does not impact the query optimizer's decision to use the index for filtering or sorting purposes.

The collection has more than 10 indexes.

Why it fails: While having too many indexes can slow down write operations, it does not prevent the optimizer from selecting an appropriate index for a read query. The optimizer evaluates all available indexes to find the best plan, regardless of the total index count on the collection.

The 'date' field is a BSON Date type.

Why it fails: BSON Date is a native, efficient type for indexing. It is fully supported in compound indexes and is highly performant. The type of the field does not cause an index to be ignored by the query optimizer.

Clear the cache manually using the dropDatabase command.

Why it fails: The dropDatabase command deletes all data in the database, which is a destructive action and does not solve cache pressure. It is not an administrative tool for managing memory or cache performance and will result in permanent data loss if executed.

Disable the WiredTiger journal to reduce write overhead.

Why it fails: The journal is essential for durability and recovery. Disabling it exposes the database to potential data corruption in the event of a crash and does not resolve cache pressure, which is primarily a memory-management issue related to the active working set.

Restart the mongod process to reset memory usage.

Why it fails: While a restart clears the cache, it is a temporary and disruptive fix that does not address the underlying issue of an inefficient working set or poor query performance. The cache pressure will return immediately as the application continues to execute the same inefficient queries.

The database process is randomly switching storage engines.

Why it fails: Storage engines are configured at the server level and cannot be switched dynamically. The engine is set when the mongod process starts and remains constant throughout the lifecycle of the instance, so this cannot be the cause of query execution plan fluctuations.

The mongos process is automatically deleting the index.

Why it fails: Mongos is a routing service and does not manage or delete indexes on shards. Indexes are permanent structures within the database collections until an administrator explicitly removes them. Therefore, an index cannot disappear on its own, making this an impossible scenario for the reported behavior.

The network latency is affecting the optimizer's choice.

Why it fails: The query optimizer makes decisions based on local collection statistics and index availability on the primary node. Network latency between the application and the database does not influence the execution plan chosen by the server, as the server is unaware of network conditions when planning.

Set the maxTimeMS to zero for all aggregation queries.

Why it fails: Setting maxTimeMS to zero disables the time limit entirely, which could lead to runaway queries consuming server resources indefinitely. This does not address the underlying resource bottleneck and risks destabilizing the primary or secondary nodes by blocking execution threads for an uncontrolled duration during high traffic periods.

Always force all aggregation queries to execute on the primary node.

Why it fails: Forcing aggregations to the primary node actually increases the load on the instance responsible for writes, potentially degrading overall cluster performance. Reads should be distributed to secondaries whenever possible using read preferences to offload the primary and improve scalability for read-heavy application workflows and complex analytical reporting.

Reduce the batch size to one to force sequential processing.

Why it fails: Reducing the batch size to one significantly increases the network round-trip overhead between the application and the database. While it might prevent memory issues, it severely impacts throughput and latency, making the application appear unresponsive to end users despite the query eventually completing its execution successfully over time.

Change write concern to w: 0.

Why it fails: While w: 0 improves latency, it provides no acknowledgment of write success, leading to silent data loss if a network error occurs. This is rarely an acceptable trade-off in production systems as it prevents the application from implementing robust retry logic or handling database write errors correctly during operation.

Increase the batch size to the maximum allowed limit.

Why it fails: Simply increasing the batch size does not automatically improve performance; it can actually cause errors if the total message size exceeds the 48MB limit for a single command. The optimal batch size depends on document size and network bandwidth, requiring careful testing rather than just maximizing the configuration constant.

Convert all indexes to hashed indexes immediately.

Why it fails: Hashed indexes are only useful for sharding and equality queries; they do not improve general write throughput. In fact, adding unnecessary indexes of any type increases the write overhead for every insert or update, as the database must perform additional work to update the index structures on disk.

Configure the application to connect to mongod instances directly.

Why it fails: Applications must connect to the mongos router, not individual mongod shards. The router is responsible for identifying where data resides and routing queries correctly. Connecting directly to shards bypasses this logic, leading to incorrect query results, data inconsistencies, and the inability to perform cross-shard operations like aggregations.

Ensure that the shard key is mutable for all documents.

Why it fails: Shard keys are generally immutable. Changing a shard key requires a manual delete and re-insert of the data, which is computationally expensive and complex. Choosing a permanent, immutable field as the shard key is a best practice that prevents the need for data migrations later in the lifecycle.

It forces the query to use the primary node for execution.

Why it fails: A hint only specifies which index the database should use to perform the search. It has no effect on the routing or read preference of the query. Read preferences are handled by the driver based on the connection string or query options, not by the index hint provided in the JSON.

It guarantees that the query will return the most recent data.

Why it fails: Index hints do not impact data freshness. Data freshness is governed by read concern and the replication lag of the secondary nodes. An index hint only controls how the query engine traverses the B-tree structure of the collection, not whether the data being read is up-to-date with the primary.

It reduces the amount of memory consumed by the mongod process.

Why it fails: While this specific query may execute more efficiently, hints do not reduce the overall memory footprint of the mongod process. Memory usage is primarily determined by the WiredTiger cache and the size of the working set, not by the specific index used to fulfill a single user request.

Modify the configuration file directly to add maxConns and restart the mongod service during a scheduled maintenance window.

Why it fails: Modifying the static configuration file requires restarting the underlying mongod service to apply changes. This causes unnecessary downtime and disruption to the running application workload, failing the operational requirement to adjust timeouts dynamically without service interruption.

Update the application connection string parameters to include maxIdleTimeMS and deploy the new configuration through rolling application restarts.

Why it fails: Connection string parameters control client-side behaviors like socket pooling and idle socket termination rather than server-side execution timeouts for running database queries. Adjusting connection settings on the client side will not resolve long-running query timeouts occurring inside the database.

Run the sh.setBalancerState(true) command to redistribute active workloads and free up resources for long-running queries across shards.

Why it fails: The balancer manages chunk migrations across shards in a sharded cluster and does not govern query execution timeouts or client session limits. Enabling or disabling the balancer has no effect on mitigating query timeouts caused by inefficient indexing or restrictive operation limits.

"local"

Why it fails: The local read concern returns data from the queried node without guaranteeing that the data has been written to a majority of replica set members. In a failover, a read with local could return data that is later rolled back. For a financial application that must never observe uncommitted or rolled-back data, local does not provide the required durability guarantee.

"snapshot"

Why it fails: The snapshot read concern provides a consistent snapshot of data across shards for a single aggregation or find operation, but it does not by itself guarantee that the data has been committed to a majority of replica set members. It is intended for multi-document transactions and sharded reads, not as a replacement for majority durability in this scenario.

"available"

Why it fails: The available read concern is designed for sharded clusters and returns data with no consistency guarantees; it is the default for reads against shards. It can return orphaned or uncommitted documents. Using available on a replica set for a financial workload would violate the requirement that reads never see uncommitted or rolled-back data.

Set read concern to "majority" for all reads inside the transaction.

Why it fails: While majority read concern provides stronger durability, it is not required for read-your-own-writes within a transaction. Transactions already provide read-your-own-writes by default when using the same session. Setting majority may increase latency and is not the practice that enables automatic retry or read-your-own-writes. The question asks for practices to ensure retry and read-your-own-writes, not durability.

Disable retryable writes to avoid duplicate operations.

Why it fails: Disabling retryable writes would prevent the driver from automatically retrying transient errors, which is the opposite of what the team needs. Retryable writes are safe because they use transaction numbers to avoid duplicates. Turning them off would force the application to handle retries manually and could lead to inconsistent state if retries are not implemented correctly.

Set write concern to 0 (unacknowledged) to improve performance.

Why it fails: Write concern 0 means the application does not wait for any acknowledgment from the server. Transactions require acknowledged writes to function correctly; unacknowledged writes cannot be part of a transaction and would break the atomicity and retry semantics. Using write concern 0 would prevent the driver from knowing whether the transaction succeeded, making retries impossible and risking data loss.

Reads will be served from the nearest member regardless of its role.

Why it fails: The nearest read preference selects a member based on network latency, not role. With secondaryPreferred, the driver prefers secondaries regardless of latency. The nearest mode would consider both primaries and secondaries and choose the one with the lowest round-trip time. So the behavior described is for nearest, not secondaryPreferred, and does not match the scenario.

Reads will be served from the primary because secondaries are lagging.

Why it fails: With secondaryPreferred, the driver attempts to read from a secondary if one is available, regardless of lag. It does not automatically fall back to the primary based on replication lag. The primary would only be used if no secondaries are available. Therefore, the application should not expect reads to be served from the primary solely because secondaries are lagging.

Reads will fail with a timeout because secondaries are lagging.

Why it fails: Lagging secondaries do not cause reads to fail with a timeout by default. The driver will still read from a secondary, and the server will return data as of the majority commit point. If the lag is extreme and the majority commit point is behind, reads may return older data, but they will not fail unless a maxTimeMS is set and exceeded. There is no automatic timeout based solely on replication lag.

w=1 with j=false

Why it fails: w=1 with j=false requires acknowledgment from the primary but does not require journaling. This provides basic write acknowledgment but does not introduce spurious duplicate key errors during network partitions. In fact, during a partition, the primary might step down, and writes could fail with a different error. The duplicate key error is not related to journaling.

w=0

Why it fails: w=0 (unacknowledged write concern) means the driver does not wait for any acknowledgment from the server. It does not cause duplicate key errors; it simply returns immediately without confirming success. Duplicate key errors are typically reported by the server when a unique index violation occurs, but with w=0 the client might not receive them. This setting is not the cause of the reported spurious duplicate key errors.

w=1 with wtimeout=1000

Why it fails: w=1 with wtimeout=1000 means the write must be acknowledged by the primary, but if it takes longer than 1000 ms, the write concern times out and returns an error. This does not cause duplicate key errors; it causes a write concern timeout error. The timeout may occur during a network partition, but the error would be a timeout, not a duplicate key violation.

readPreference: "primary", readConcern: "majority"

Why it fails: This combination reads from the primary with majority read concern, which ensures durability but does not allow reads from secondaries. The requirement includes the ability to read from secondary nodes to reduce load on the primary, so this does not satisfy the need for secondary reads.

readPreference: "secondary", readConcern: "linearizable"

Why it fails: "linearizable" read concern cannot be used with a secondary read preference because it requires reading from the primary to provide the strongest consistency. MongoDB will reject this combination. Therefore, it is not a valid configuration for reading from secondaries with rollback safety.

readPreference: "secondaryPreferred", readConcern: "local"

Why it fails: "local" read concern does not guarantee that the data has been replicated to a majority of members, so it can return rollback-able data. While "secondaryPreferred" allows reading from secondaries, the combination with "local" fails to meet the requirement that reads must not return rollback-able data.

readConcern: local with readPreference: secondary

Why it fails: local read concern does not guarantee that the data has been acknowledged by a majority of replica set members. It can return data that has not yet been replicated to a majority, and thus could be rolled back. Even though it reads from secondaries, it fails the requirement of majority acknowledgment. Therefore, it is not a correct choice.

readConcern: linearizable with readPreference: secondary

Why it fails: linearizable read concern provides the strongest consistency guarantee but can only be used with readPreference: primary. It cannot be combined with readPreference: secondary; MongoDB will return an error if you attempt this combination. Thus, it does not satisfy the requirements and is not a valid choice.

readConcern: available with readPreference: secondary

Why it fails: available read concern provides the weakest consistency and does not guarantee majority acknowledgment. It is similar to local but with even fewer guarantees in sharded clusters. Reading from secondaries with available read concern may return data that is not majority-committed and could be rolled back. This fails the requirement.

Read the document, update the value in application code, and save the document.

Why it fails: This approach is prone to race conditions, known as a 'lost update.' If two processes read the document simultaneously, they will both modify the same initial state, and the final save will overwrite the other, resulting in inaccurate balance data for the user.

Wrap the operation in a multi-document transaction every time.

Why it fails: While transactions are valid for atomicity, they introduce significant performance overhead for simple, single-document updates. Using unnecessary transactions consumes system resources and increases latency, which is suboptimal for high-frequency operations that can be handled atomistically by standard update operators.

Use a global application-level mutex lock before updating.

Why it fails: Application-level locking is fragile and does not scale across multiple instances of an application. Furthermore, it adds complexity and latency. MongoDB provides atomic operators specifically to avoid this type of external locking, making it the preferred method for maintaining data consistency.

Increase the RAM allocated to the mongod process configuration.

Why it fails: The 100MB limit for aggregation stages is a hardcoded constraint in MongoDB. Increasing the overall RAM available to the mongod process does not change this limit, meaning the error will persist regardless of the available system memory unless allowDiskUse is used.

Remove the $group stage and perform the grouping in application code.

Why it fails: Moving the grouping logic to the application is highly inefficient as it requires transferring massive amounts of raw data over the network. This increases latency and consumes application memory, which is exactly what the database aggregation framework is designed to avoid.

Reduce the batch size in the cursor options.

Why it fails: Batch size affects the data transfer rate between the server and client, but it has no impact on the internal memory usage of the aggregation pipeline stages. Reducing it will not prevent the $group memory limit error, which is an internal server-side processing constraint.