A sharded cluster instance distributes data across multiple shard nodes. Requests from your application go to mongos nodes, which route each query or write to the correct shard. Add shard nodes to scale storage and throughput horizontally; mongos handles load balancing and failover across the cluster.
Architecture
A sharded cluster instance consists of three component types: mongos, shard, and ConfigServer nodes.
| Component | Topology | Node count | Description |
|---|---|---|---|
| Mongos | Standalone | Up to 32 per instance (by default) | Routes queries and writes to the corresponding shard nodes. Deploy multiple mongos nodes to distribute traffic and provide failover. |
| Shard | Replica set (primary, secondary, and hidden nodes + read-only nodes) | Up to 32 per instance (by default) | Stores database data. Add shard nodes to scale out storage capacity and concurrent read and write throughput. |
| ConfigServer | Replica set (three nodes) | 3 | Stores the metadata for each shard node, including the types of data stored in each shard node. |
Read-only nodes are not included in the default shard configuration and must be purchased separately. The price of a single read-only node equals that of a single shard node.
VPC IP allocation
When you create a sharded cluster instance in a VPC, the VPC IP allocation rules for each component are as follows:
|
Component |
IP allocation rule |
|
Mongos |
Each Mongos node occupies 1 VPC IP. |
|
Shard |
Does not occupy VPC IP by default. Only when you apply for a Shard address, the system enables direct connection for the Shard, and each Shard (primary and secondary nodes) occupies 2 VPC IPs. Applying for a Shard address is typically used for DTS data export scenarios. |
|
Configserver |
Does not occupy VPC IP. |
After you apply for a Shard address, the total number of VPC IPs = Number of Mongos nodes × 1 + Number of shards × 2. If you do not apply for a Shard address, the total number of VPC IPs = Number of Mongos nodes × 1.