Starting in 8.0, sharded cluster will be the only supported topology in MongoDB. Upon upgrading to 8.0, existing replica set or standalone will be bootstrapped as a sharded cluster with a single shard which is also the config shard (PM-2966). MongoD will be capable of acting as a router. There will be a shard port and a router port (PM-635).

The replica set endpoint will allow users to continue to connect upgraded "replica set" or "standalone" using the existing connection string (one that points to the shard port) while doing so they can continue to use the "replica set" or "standalone" just like they did but also not miss out on new features which will likely be available through a router only due to the shift to sharding-only development. To achieve that, on the shard port MongoD will return mongod hello responses (required to make existing connections to continue to work) but make commands go through the router code paths except in the cases listed here https://docs.google.com/document/d/1Ipj5MGzaCwN3Y2JX0VrRkCKa_cY-wx8089PFMjvviIo/edit?pli=1#bookmark=kix.vrqatxgpm10g. To bypass the router code paths completely, the MongoD will need to started with –maintenanceMode=<replicaSet|standAlone> https://docs.google.com/document/d/1Oa9w4hYi-RFmpyM8Mv9D70Wox8O2w_9O6rvOy57XuQs/edit#bookmark=id.fn0qn8jd6wgd.

Most teams have been engaged in the design review process. The Cloud teams already have plans to test PM-2966, PM-635 and PM-2965 altogether. The driver teams should add test cases for connecting to the shard port instead of the router port of single-shard cluster as described above.

Description of Linked Ticket

Summary

In this project, we will build a Replica Set emulation layer that will:

• Return underlying replica set node information to drivers during the connection handshake.
• Authenticate and manage users with cluster-wide credentials.
• Send all queries, mutations, and commands through the mongos routing + execution code paths.

All database requests will be serviced through the MongoDB sharded topology layers.

Additionally, many replica set users whose applications depend on low latency operations will not tolerate an additional availability zone hop to service requests until they need horizontal scalability. By emulating the replica set handshake behavior for single-shard clusters, MongoDB drivers can continue to offer low-latency write requests that directly target the appropriate node for the operation. This will allow us to protect the integrity of the cluster by disallowing direct connections to the shards except through mongos.

Motivation

We want all database requests to be serviced through sharding code paths by 7.2 to achieve sharding-only development. However, we cannot control when existing users will restart their applications (resolving a new SRV record) or migrate their applications to a sharded connection string.

If users delay modifying their connection string (potentially by not restarting their app) they’ll continue to bypass the sharding code paths and prevent us from achieving sharding only development. We need to provide a mechanism for users to connect and send requests to what they believe is a replica set without changing their connection string or restarting their application.

Documentation

Scope Document
Technical Design