Sharding practice questions

The shard key value cannot be null for any document.

Why it fails: MongoDB allows shard key values to be null. If a document lacks the shard key field, it is indexed as null and placed in the chunk corresponding to the null range. While technically allowed, having many null values can lead to 'jumbo chunks' and poor data distribution across the cluster.

The shard key must be the same as the _id field for all collections.

Why it fails: While the _id field can be used as a shard key, it is not a requirement. Developers often choose a different field that better reflects the application's query patterns. Using _id as the shard key provides uniqueness but may not offer the best query targeting or write distribution for every workload.

Shard keys must be defined as unique indexes at the cluster level.

Why it fails: A shard key does not have to be unique unless the application requires it. If you want a unique constraint on a sharded collection, the shard key must be a prefix of the unique index. Otherwise, MongoDB cannot enforce uniqueness across multiple shards because it would require expensive cross-shard communication.

The collection must be dropped and recreated with the new key.

Why it fails: One of the primary advantages of refining a shard key is that it does not require dropping the collection or downtime. The operation is performed online using the refineCollectionShardKey command, allowing the database to continue serving requests while the metadata is updated and new chunk boundaries are established.

The balancer must be disabled during the entire refinement process.

Why it fails: While the balancer manages chunk migrations, it does not need to be manually disabled for the refinement process. MongoDB handles the metadata update internally. However, once the key is refined, the balancer will start using the new key to make more informed decisions about how to distribute data across the shards.

All shards must be running the Enterprise Edition of MongoDB.

Why it fails: Shard key refinement is a feature available in both MongoDB Community and Enterprise editions starting with version 4.4. It is a core architectural improvement designed to provide better scalability for all users, regardless of their licensing model, by addressing the common problem of low-cardinality shard keys.

The chunk is immediately moved to another shard to balance the load.

Why it fails: Splitting and migrating are two separate processes. A split simply divides a large chunk into two smaller ones on the same shard. The balancer may later decide to move one of those new chunks to a different shard to maintain balance, but the move does not happen automatically as part of the split.

The collection becomes read-only until a DBA manually splits the chunk.

Why it fails: Chunk splitting is an automatic process handled by the MongoDB system. It does not require manual intervention and does not impact the availability of the collection for write operations. If a chunk cannot be split because it only contains a single shard key value, it becomes a jumbo chunk.

The shard key is automatically changed to provide better distribution.

Why it fails: The shard key is a permanent part of the collection's configuration and cannot be changed automatically by the system. If a shard key is poorly chosen and leads to chunks that cannot be split, the DBA must take manual action, such as refining the shard key or resharding the collection.

Temporarily stop all incoming application write operations across all mongod instances to prevent race conditions during chunk allocation.

Why it fails: Temporarily stop all incoming application write operations across all mongod instances to prevent race conditions during chunk allocation. Shard collection operations run concurrently with live application traffic without requiring cluster-wide write maintenance windows or downtime.

Run the compact command on every underlying data file to defrag storage before shard boundary calculations execute.

Why it fails: Run the compact command on every underlying data file to defrag storage before shard boundary calculations execute. Compacting data files is an unnecessary maintenance task that does not influence shard key validation or initial chunk boundary determination mechanisms.

Convert all ObjectId fields inside the target collection into standard string representations to satisfy BSON sharding constraints.

Why it fails: Convert all ObjectId fields inside the target collection into standard string representations to satisfy BSON sharding constraints. MongoDB natively supports ObjectId values as valid shard key components without requiring costly document transformations or type conversions.

The balancer requires every individual shard in the cluster to be configured as a standalone mongod instance for optimal migration speed.

Why it fails: The balancer requires every individual shard in the cluster to be configured as a standalone mongod instance for optimal migration speed. Shards in production must be configured as replica sets to ensure high availability; standalone shards are unsupported for production environments.

Disabling the balancer permanently deletes all existing chunk distribution boundaries and collapses the collection into a single unsharded file.

Why it fails: Disabling the balancer permanently deletes all existing chunk distribution boundaries and collapses the collection into a single unsharded file. Disabling the balancer merely stops automated chunk migrations; it preserves all existing chunk boundaries and data locations across the cluster shards.

Changing a shard key automatically triggers an unrecoverable corruption of the WiredTiger storage engine's internal block allocation tables.

Why it fails: Changing a shard key automatically triggers an unrecoverable corruption of the WiredTiger storage engine's internal block allocation tables. Storage engine block allocations remain completely unaffected by sharding configurations or metadata adjustments.

Updating a shard key requires restarting every mongos instance in the cluster simultaneously to flush query routing caches.

Why it fails: Updating a shard key requires restarting every mongos instance in the cluster similarly to flush query routing caches. Mongos query routers automatically refresh their metadata caches from the config servers without requiring manual query router restarts.

Modifying a shard key invalidates all secondary indexes across all shards, forcing a complete cluster-wide index rebuild from scratch.

Why it fails: Modifying a shard key invalidates all secondary indexes across all shards, forcing a complete cluster-wide index rebuild from scratch. Secondary indexes remain valid for queries but are not automatically transformed into new shard key structures without explicit administrative intervention.

Connect to the config server primary and run rs.addShard("rs4/host1:27017,host2:27017,host3:27017")

Why it fails: rs.addShard() is not a valid MongoDB command. The rs namespace contains replica set methods like rs.add() and rs.initiate(), but no addShard method. Config servers store cluster metadata but do not expose shard management commands. Adding a shard must be performed through mongos, which coordinates the operation with the config servers.

Connect to mongos and run sh.addShard("rs4", "host1:27017,host2:27017,host3:27017")

Why it fails: sh.addShard() takes a single string argument in the form "replicaSetName/host1:port,host2:port". Passing the replica set name and host list as two separate arguments is invalid syntax and will cause the command to fail. The correct format concatenates the set name and members with a forward slash and commas.

Connect to mongos and run db.runCommand({addShard: "rs4/host1:27017,host2:27017,host3:27017"}) on the admin database

Why it fails: While the addShard command exists, it must be run against the admin database. Running db.runCommand() from a non-admin database context will fail because addShard is an admin-only command. The helper sh.addShard() automatically targets the admin database and is the preferred method.

Use a hashed shard key on the timestamp field.

Why it fails: Hashing the timestamp field would distribute writes evenly but would destroy the ability to perform efficient range queries on timestamp. The application frequently queries by timestamp range, so hashing would force scatter-gather across all shards, which is inefficient. It also does not help with queries that filter by `deviceId`.

Use a random shard key generated by the application for each document.

Why it fails: A random shard key provides excellent write distribution but makes queries inefficient because the application cannot predict which shard holds a document. Since queries filter by `deviceId` and timestamp, a random key would force scatter-gather for almost all queries, severely impacting performance. It is not a suitable strategy for this workload.

Use a hashed shard key on `deviceId`.

Why it fails: A hashed shard key on `deviceId` distributes writes evenly, but it prevents efficient range queries on `deviceId` because hashing destroys order. Since queries often filter by `deviceId` and timestamp, this choice would force scatter-gather for many queries, reducing performance. It also does not support range queries on timestamp.

The queries will still be targeted because MongoDB automatically uses the most selective field in the shard key for routing.

Why it fails: MongoDB does not automatically choose the most selective field for routing. Routing is strictly based on the shard key prefix. If the query does not include the prefix, mongos cannot target shards. The selectivity of other fields is irrelevant for routing decisions.

The shard key can be refined by adding customerId as a prefix using the refineCollectionShardKey command.

Why it fails: The refineCollectionShardKey command can only add fields to the end of an existing shard key, not change the prefix or reorder fields. Since region is already the prefix, you cannot make customerId the prefix. The only way to change the shard key prefix is to reshard the collection, which is a separate operation.

The queries can be optimized by creating an index on customerId alone on every shard.

Why it fails: While an index on customerId can improve performance within each shard, it does not allow mongos to avoid contacting all shards. The query is still scatter-gather because routing decisions are based on the shard key, not secondary indexes. The index only speeds up the local scan on each shard, not the fan-out.

Run sh.splitFind("mydb.accounts", { accountId: 3000 }) after disabling the balancer, because splitFind requires the balancer to be stopped.

Why it fails: sh.splitFind splits a chunk at its median point, not at a specified value, and it does not require disabling the balancer. The scenario requires splitting at the exact value 3000, which splitFind cannot guarantee. Disabling the balancer is unnecessary and adds risk during a heavy-load period without providing the desired precise split.

Manually update the config.chunks collection to insert a new chunk document with the boundary at 3000 and refresh the mongos caches.

Why it fails: Directly modifying config.chunks is unsupported and dangerous; it can corrupt cluster metadata and cause routing errors. The supported path is to use sh.splitAt or sh.splitFind through mongos. Manual edits bypass validation and can leave the cluster in an inconsistent state, especially under load with the balancer active.

Restart the mongos processes with the --splitChunks option so the cluster automatically splits chunks at their midpoint during startup.

Why it fails: There is no --splitChunks startup option for mongos that performs chunk splitting. Chunk splitting is managed through the sh.splitAt and sh.splitFind commands or automatically by the cluster when chunks exceed the maximum size. Restarting mongos would disrupt client connections and would not achieve the targeted split at 3000.

The balancer will move chunks too frequently, causing network saturation.

Why it fails: While the balancer moves chunks to maintain even distribution across the cluster, it does not solve the immediate problem of a single shard receiving all incoming writes. Excessive balancing can consume bandwidth, but the primary bottleneck here is the inability to parallelize the ingestion process across multiple shards.

Read operations will fail because the query router cannot locate the data.

Why it fails: The mongos query router uses metadata from config servers to identify which shard contains specific ranges. While write performance suffers, read operations remain functional. The router successfully maps the shard key to the correct shard, but the overall cluster health is degraded due to the uneven write load distribution.

The shard key must be unique, and timestamps often collide in high-volume systems.

Why it fails: MongoDB does not require shard keys to be unique unless they are also the primary key. If multiple documents share a timestamp, they simply belong to the same chunk. The bottleneck is physical resource exhaustion on one shard, not a constraint violation or index conflict within the database engine.

Automatic failover and high availability for the entire cluster.

Why it fails: While each shard is typically a replica set that provides high availability, sharding itself is focused on horizontal scaling and data distribution. High availability is a property of the replica set architecture used within the shards, rather than a benefit introduced specifically by the sharding layer of the cluster.

Simplified backup and recovery processes for large datasets.

Why it fails: Sharding actually increases the complexity of backup and recovery operations. Backing up a sharded cluster requires coordinating snapshots across all shards and config servers to ensure point-in-time consistency. This is generally more difficult and resource-intensive than managing a single standalone replica set or a single node.

Reduced latency for all queries regardless of the shard key used.

Why it fails: Sharding only reduces latency for queries that can be targeted to specific shards using the shard key. Queries that do not include the shard key must be broadcast to all shards, which often results in higher latency and increased resource consumption compared to a non-sharded environment.

Hashed sharding does not support compound shard keys.

Why it fails: MongoDB supports hashed sharding on a single field, and as of version 4.4, it also supports compound hashed shard keys. This allows developers to combine a hashed field with one or more ranged fields to achieve both write distribution and some level of query targeting for specific applications.

Hashed sharding requires the shard key field to be a numeric type.

Why it fails: The hashing algorithm used by MongoDB can process various data types, including strings and ObjectIDs. There is no requirement that the shard key be a numeric value. The database calculates a 64-bit hash of the field value regardless of its original type to determine the document's chunk.

Hashed sharding cannot be used with the balancer to move chunks.

Why it fails: The balancer works identically for both hashed and ranged sharding. It monitors the distribution of chunks across shards and performs migrations as needed to maintain balance. The internal representation of ranges in hashed sharding is simply based on the hash values rather than the literal field values.

Use a cron job to call sh.stopBalancer() and sh.startBalancer().

Why it fails: While external scripts can control the balancer, it is not the recommended or native way to manage maintenance windows. Using the built-in activeWindow configuration is more robust and less prone to failure compared to managing external processes that might fail to execute the start or stop commands correctly.

Modify the mongod configuration file to include a balancing schedule.

Why it fails: The balancer's operational window is a cluster-wide setting stored in the config servers' metadata, not a parameter in the local mongod configuration files. Changing local config files would not affect the behavior of the balancer, which is a distributed process coordinated by the query routers and config replica set.

Set a TTL index on the chunks collection to expire migrations.

Why it fails: TTL indexes are used to automatically remove expired documents from a collection based on a date field. They have no relationship to the balancer's logic or the timing of chunk migrations. Attempting to use a TTL index on internal metadata collections would be dangerous and would not achieve the desired scheduling.

Replica set tags for read preferences.

Why it fails: Replica set tags are used to route read operations to specific members within a single replica set based on their attributes. While useful for localizing reads, they do not control the physical storage location of data across multiple shards in a cluster, which is required for data residency compliance.

Hashed sharding with a geo-spatial index.

Why it fails: Hashed sharding randomizes data distribution and is fundamentally incompatible with the goal of keeping specific data on specific shards. Geo-spatial indexes help with location-based queries but do not provide the administrative control needed to restrict data placement to specific physical hardware or geographic regions in a cluster.

The movePrimary command for each database.

Why it fails: The movePrimary command changes the default shard for all unsharded collections in a database. It cannot be used to distribute individual documents or ranges of a sharded collection based on their field values. Consequently, it is an inappropriate tool for managing granular data residency across multiple regions.

A dedicated arbiter node for each shard.

Why it fails: Arbiters are optional components in a replica set that participate in elections but do not store data. While they can be used within the replica sets that make up a shard, they are not a required component of the sharding architecture itself and are generally discouraged in production environments.

A central MongoDB Ops Manager instance.

Why it fails: Ops Manager is a management platform for automation, monitoring, and backup of MongoDB deployments. While highly recommended for managing complex sharded clusters, it is an auxiliary tool and not a technical requirement for the cluster itself to function and process data requests from an application.

The field is not a unique identifier for the documents.

Why it fails: Shard keys are not required to be unique identifiers. Many documents can share the same shard key value. The problem here is the lack of variety in those values, which prevents the database from splitting the data into enough chunks to distribute across a larger number of shards.

The field type must be an ObjectID for performance reasons.

Why it fails: There is no requirement that a shard key be an ObjectID. Any BSON type can be used as a shard key. The performance of a shard key depends on its cardinality and write pattern rather than its specific data type, provided the field is indexed and consistently present.

The balancer cannot migrate chunks based on string values.

Why it fails: The balancer is perfectly capable of migrating chunks regardless of the data type of the shard key, including strings. It operates on range boundaries defined by the BSON sort order. The issue is the limited number of ranges available for migration when the set of values is so small.

The query will be rejected by the mongos as an invalid operation.

Why it fails: MongoDB allows queries that do not include the shard key. The mongos router will still attempt to execute the query by sending it to all shards. While inefficient, it is a valid operation, provided the query is otherwise syntactically correct and the user has the necessary permissions.

The query will only be sent to the primary shard of the database.

Why it fails: The primary shard only stores unsharded collections for a database. For a sharded collection, the data is distributed across many shards. A query without the shard key must be sent to every shard that might contain data for that collection, not just the database's primary shard.

The cluster will automatically create a new index to support the query.

Why it fails: MongoDB does not automatically create indexes based on query patterns. Indexing is an administrative task. Furthermore, even with an index on the queried field, the mongos still needs the shard key to target specific shards; otherwise, the index lookup must still occur on every shard.

The primary node of the config server replica set.

Why it fails: Config servers store metadata and cluster configuration but do not coordinate application-level transactions. Their role is to provide the routing information that allows the mongos to find the relevant shards. The actual logic for managing the transaction state and the two-phase commit resides on the mongos instance.

The shard that contains the first document accessed in the transaction.

Why it fails: While the shards involved in a transaction are participants, no single data shard acts as the global coordinator for a distributed transaction. Each participant shard is responsible for its local part of the transaction, but the overall coordination and the decision to commit are managed by the mongos router.

A specialized 'Transaction Manager' node that must be configured.

Why it fails: MongoDB does not have a separate 'Transaction Manager' node type. The transaction coordination functionality is built into the existing mongos and mongod binaries. This design simplifies the cluster architecture by reusing the established communication paths between the query routers and the data shards for transaction management.

The cluster becomes read-only for all application data.

Why it fails: The loss of config server majority only affects the cluster's metadata. Application data stored on the shards remains accessible for both reads and writes. As long as the shards themselves are healthy and the mongos instances have cached the necessary routing information, the application can continue to function normally.

The mongos instances will crash and must be restarted.

Why it fails: Mongos instances are designed to be resilient. They cache routing metadata locally. While they will be unable to refresh this cache if the config servers are unavailable, they do not crash. They will continue to route requests based on their existing cache until the config servers return to service.

All shards will automatically step down their primary members.

Why it fails: The health of the shard replica sets is independent of the config server replica set. Shards use their own internal heartbeats and elections to maintain a primary. The loss of config server availability does not trigger any changes to the leadership or state of the individual shard replica sets.