edit-icon download-icon

Connect to cluster instances

Last Updated: Jan 17, 2018

Background information

MongoDB sharding instances stores data distributed across multiple shards, to achieve high scalability. To use sharding instances, MongoDB introduces ConfigServer to store cluster metadata and introduces mongos to serve as application access portals. Mongos read route information from the ConfigServer and route requests to the corresponding shards at the backend.

Sharding cluster

  • Users access mongos in a way similar to accessing a single mongod.

  • All mongos have an equivalent relationship. Users can access the Sharded Cluster through any one or more mongos.

  • Mongos themselves are stateless and can be arbitrarily scaled. The cluster service capability is either the “sum of shard service capabilities” or the “sum of mongo capabilities”, whichever value is lower.

  • When accessing Sharded Cluster, it is best to evenly distribute application loads among multiple mongos.

How to properly connect to sharding instances?

All official MongoDB drivers support using the Connection String method to connect to MongoDB sharding instances.

The main contents of the Connection String are listed as follows:

  1. mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]
  • The mongodb:// prefix indicates that this is a Connection String.

  • username:password@ specifies the user name and password if authentication is enabled.

  • hostX:portX lists the addresses of multiple mongos.

  • /database indicates the database to which the user account belongs during authentication.

  • ?options indicates the additional connection options.

Here we present a connection example using ApsaraDB for MongoDB. After purchasing MongoDB sharding instances, you can see the address information for each mongo on the console.

Mongos addresses

For ease of use, the console also generates replica set Connection Strings and Mongo Shell connection commands.

Connection commands

Sample code for Java connection is shown as follows:

  1. MongoClientURI connectionString = new MongoClientURI("mongodb://:****@s-m5e80a9241323604.mongodb.rds.aliyuncs.com:3717,s-m5e053215007f404.mongodb.rds.aliyuncs.com:3717/admin"); // ****Replace with root password
  2. MongoClient client = new MongoClient(connectionString);
  3. MongoDatabase database = client.getDatabase("mydb");
  4. MongoCollection<Document> collection = database.getCollection("mycoll");

When using the preceding method to connect to sharding instances, the client automatically distributes the requests to multiple mongos, to achieve load balancing. Meanwhile, when the URI includes two or more mongos and one of the mongos encounters a fault, the client automatically performs failover to distribute all requests to mongos in the normal status.

When you have many mongos, they can be grouped by application. For example, if we have two applications, A and B, and 4 mongos, we can configure application A to access mongos 1 and 2 (only specify the addresses for mongos 1 and 2 in the URI) and configure application B to access mongos 3 and 4 (only specify the addresses for mongos 3 and 4 in the URI). This method can be used to achieve access isolation between applications (the mongos accessed by various applications are mutually isolated, but the backend shards are still shared).

App sharding

In short, when accessing sharding instances, make sure that the MongoDB URI contains 2 or more mongo addresses, so that loads are balanced and high availability is assured.

Common connection parameters

  • How to implement read/write splitting?

    To implement the read/write splitting, add readPreference=secondaryPreferred to options, which prioritizes read requests to the secondary nodes.

  • How to limit the number of connections?

    Add maxPoolSize=xx in options to limit the client connection pool to xx connections.

  • How to guarantee that data is written to the majority of nodes before the result is returned?

    Add w= majorityin options to make sure that write requests are successfully written to the majority of nodes before confirmation is sent to the client.

Thank you! We've received your feedback.