mongos is the gateway between client applications and a sharded MongoDB cluster. It uses metadata from config servers to route read and write operations to suitable shards, then combines shard results into one client response. Applications and tools such as mongosh connect through mongos rather than directly to shards. section 1.2 section 9.3.1
Plan mongos deployments around availability, connection behavior, and routing overhead:
- Run multiple mongos instances in production to improve high availability. section 9.3.1
- Configure client affinity, or sticky sessions, when a proxy or load balancer sits between clients and mongos. section 1.2
- Add routers cautiously: frequent communication with config servers can degrade performance; the guidance recommends fewer than 30 mongos routers. section 1.2
- Embed mongos at the application level or add instances on existing hardware when shard-level high availability requires more routing capacity. section 1.2
Connect to an Atlas sharded cluster
Atlas automates deployment of shards, config servers, and mongos processes. After obtaining the connection string, connect with mongosh: `mongosh "mongodb+srv://mongodb-in-action-shard.nu96v.mongodb.net" --apiVersion 1 --username 'manning'`. The prompt identifies the connection as `Atlas [mongos]`, confirming that the client is using the query router. section 9.3.2
Figure 9.2 This MongoDB sharded cluster configuration includes multiple app servers connected to routers (mongos), which direct queries to the appropriate shard. Three shards, each of which is a replica set, hold segments of the data. Also, an embedded config shard contains the config servers (along with user data), which hold the cluster’s metadata. Starting with MongoDB 8.0, config servers can be embedded in sharded clusters. (Image © MongoDB 2024 CC BY-NC-SA 3.0)
Use the sharded-cluster architecture to trace how application servers connect to mongos, how routers direct queries to replica-set shards, and how config servers provide metadata. section 9.3.1
