Cluster¶
Each DDS cluster is an independent document database. A sharded cluster consists of a config node, and multiple dds mongos and shard nodes.
Data read and write requests are forwarded by the dds mongos nodes, which read configuration settings from config, and then allocate the read and write requests to the shards, making it easy to cope with high concurrency scenarios. In addition, each config node, along with the shards in its cluster, is replicated in triplicate to ensure high availability. The following figure shows the DDS cluster architecture.
Figure 1 Cluster architecture¶
A driver handles all interactions between your application and the database in a language appropriate to the application. For details, see official documents.
Each dds mongos is a single node, but you can provision multiple dds mongos nodes for load balancing and failovers. A single cluster can contain 2 to 32 dds mongos nodes.
Each shard is a three-node replica set, and each cluster can contain 2 to 32 shards.
A config node is a necessary part of a cluster instance, and is also deployed as a replica set. The config node stores instance configuration data.
The number of dds mongos and shard nodes can be increased from the management console. You do not need to use native commands.
You can enable IP addresses of shards and the config node to directly access the shards and the config node.
A three-node replica set cannot be directly upgraded to a cluster.