Sharding Insights

Resources

Hardware resource usage metrics aggregated per shard:

• System CPU: Percentage of CPU time used across all cores on the shard.

• System Memory: Amount of RAM in use on the shard.

• System Network: Total network bytes in and out per second on the shard.

• Disk IOPS: Number of disk read and write operations per second.

• Disk Latency: Average read and write latency for disk operations.

• Disk Throughput: Bytes read from and written to disk per second.

• Disk Space: Disk space used and available on the shard.

• Data Size: Uncompressed size of user data held on the shard, summed across databases. This chart is empty if database statistics collection is disabled for the project.

Workload

Query and operation throughput metrics per shard:

• Connections: Number of active client connections to the shard.

• Opcounters: Rate of insert, query, update, delete, getmore, and command operations per second.

• Queues: Number of operations waiting to acquire the global lock.

• Replication Lag: Delay in milliseconds between the primary and secondaries during replication.

• Read Latency: Average execution time of read operations on the shard.

• Write Latency: Average execution time of write operations on the shard.

• Command Latency: Average execution time of command operations on the shard.

Cache

Storage engine cache usage and efficiency per shard:

• Cache Fill Ratio: Percentage of the configured storage engine cache currently in use. A ratio near 100% indicates that the working set is larger than the cache.

• Dirty Fill Ratio: Percentage of the configured storage engine cache holding modified pages not yet written to disk. A high ratio can indicate write overload.

• Cache Hit Ratio: Percentage of page requests served from the storage engine cache without reading the page from disk.

Data Distribution

Per-shard data size, document counts, and chunk distribution for sharded collections:

• Owned Data Size: Size of data owned by each shard, summed across sharded collections.

• Orphaned Data Size: Size of orphaned data on each shard, summed across sharded collections.

• Owned Document Count: Number of documents owned by each shard, summed across sharded collections.

• Orphaned Document Count: Number of orphaned documents on each shard, summed across sharded collections.

• Chunk Count: Number of chunks on each shard across sharded collections.

• Jumbo Chunk Count: Number of jumbo chunks on each shard. The balancer cannot migrate jumbo chunks.

These metrics help you identify performance bottlenecks, capacity issues, and data distribution imbalances across your shards.

Shards Table

The shards table below the charts lists each shard with its status, data size, average and maximum CPU usage, reads per second, and writes per second for the selected time range. The table controls which shards appear in the charts. To choose which columns the table displays, click Edit Columns.

To open a detail panel for a shard, click its row. The panel displays the shard's active alerts and overview metrics, including the number of sharded collections, average read and write load, average operation execution time, cache activity, and range deleter activity.

Deployment Support

Sharding Insights does not support:

• Replica set deployments (only sharded clusters).

• Clusters running MongoDB versions earlier than 8.0.

• Clusters on tiers below M10.

• Clusters using Atlas Data Regionalization.

• Cloud Manager or Ops Manager deployments.

• Government cloud environments.

API and Automation Support

This release does not support:

• Atlas Administration API access to Sharding Insights data.

• Terraform provider support for Sharding Insights configuration.

• MongoDB MCP Server integration for Sharding Insights metrics.

These capabilities might be added in future releases.

Sharding Decisions

• Permanent Change: Converting a replica set to a sharded cluster is a permanent architectural decision that cannot be reversed.

• Planning Required: Review the sharding documentation and plan your shard key strategy before you shard a collection.

• Shard Key Selection: Choose a shard key that supports your query patterns and provides good data distribution. See Choose a Shard Key to evaluate potential shard keys.

• Test Before Production: Test your application with the selected shard key on a sharded cluster before applying it to production. Moving from a replica set to a sharded cluster may expose differences in functionality and performance. Validate that your application handles these differences appropriately.

Write Operation Semantics

Sharded clusters have different write operation semantics than replica sets:

• Multi-Document Operations: Use updateMany() and deleteMany() only for idempotent writes on sharded collections. These operations may execute more than once on some documents if there are network errors or failovers during execution.

• Retryable Writes: MongoDB provides retryable writes for single-document operations to handle transient failures, but multi-document operations require careful design.

• Write Concern: Review your application's write concern settings to ensure they align with your durability requirements in a sharded environment.

Review the sharding operational restrictions before you shard your cluster.

Network Considerations

• PrivateLink Impact: If your cluster uses PrivateLink, converting from a replica set to a sharded cluster will completely block connectivity to the shards. Your application will experience downtime until it is restarted and reconnects to the mongos router.

• Connection Updates: When you convert from a replica set to a sharded cluster, your application must restart to reconnect to the mongos router. If your application uses an SRV connection string, no changes to the connection string are needed, but the application restart is still required. Adding shards to an existing sharded cluster does not require an application restart.

Collection Movement Constraints

When you move collections between shards:

• One at a Time: Only one collection can be moved at a time.

• No Write Blocking: Collection moves use resharding, which allows write operations to continue during the move.

• Destination Capacity: The destination shard must have sufficient storage and resource capacity.

• Operation Time: Large collections might take significant time to move.