Mongodb – Set or limit number of connections a single pymongo client will open

You cannot run a mongos without a config server, but you shouldn't have to in order to "scale up" your connections in any case - all you would be doing is adding an unnecessary layer between the driver you are using and the replica set. Unless you are using sharding, having that layer is not necessary, and can introduce performance issues in some cases (such as unbatching delays).

Your driver (which you don't mention) will have connection pool settings (the Java version can be found here) and perhaps multiplier options to determine how many connections you will open to your replica set, and how many threads will block and wait for a connection from the pool.

Some general advice:

• If you do go down the route of having a single shard (which is what your replica set would effectively become with config servers and mongos processes), then do not run with a single config server - always run with 3 config servers in production, period.
• Be careful with connections - each connection on the MongoDB side will require 1MB of memory (as will each connection on a mongos). If you ramp up connection levels you will be using memory for connection heap rather than data - this can be significant (10GB of memory for 10,000 concurrent connections)
• If you do ramp up connections, make sure your ulimit settings can handle it

Finally, this use of mongos as a general proxy has been proposed before. In theory it would simplify some of the driver code needed if there was always a mongos in the connection path, but it is not as simple as just allowing it. The relevant feature request can be found (and voted for, watched etc.) here:

https://jira.mongodb.org/browse/SERVER-1594

If your client applications are connecting directly to MongoDB, they will typically use a connection string which varies depending on the type of deployment:

• Standalone - mongod hostname (and optionally, port)
• Replica set - includes one or more mongod hosts in the replica set as a "seed list" to discover the current configuration
• Sharded cluster - includes one or more mongos hosts to connect to the sharded cluster

There isn't a direct equivalent of the "logical connection" abstraction. However, since you are already connecting via mongos, it sounds like you have a sharded cluster which does abstract the connection details for the underlying shards. All mongos connecting to the same cluster have to use the same --configdb list.

If you deploy a mongos per application host, each application can connect to the mongos on localhost. Alternatively you could have a fixed set of shared mongos and expose these via DNS cnames that resolve to "local" mongos for that application or data centre.

If you want to further lockdown per-client access, each client application could authenticate using different credentials which limit their access/permissions per-database. MongoDB 2.6 adds further granularity including collection-level access. For more information see Security Concepts in the MongoDB manual.