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.
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.
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:
mongodb://prefix indicates that this is a Connection String.
username:password@specifies the user name and password if authentication is enabled.
hostX:portXlists the addresses of multiple mongos.
/databaseindicates the database to which the user account belongs during authentication.
?optionsindicates 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.
For ease of use, the console also generates replica set Connection Strings and Mongo Shell connection commands.
Sample code for Java connection is shown as follows:
MongoClientURI connectionString = new MongoClientURI("mongodb://:****@s-m5e80a9241323604.mongodb.rds.aliyuncs.com:3717,s-m5e053215007f404.mongodb.rds.aliyuncs.com:3717/admin"); // ****Replace with root password
MongoClient client = new MongoClient(connectionString);
MongoDatabase database = client.getDatabase("mydb");
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).
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.
How to implement read/write splitting?
To implement the read/write splitting, add
readPreference=secondaryPreferredto options, which prioritizes read requests to the secondary nodes.
How to limit the number of connections?
maxPoolSize=xxin 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?
w= majorityin options to make sure that write requests are successfully written to the majority of nodes before confirmation is sent to the client.