proposalbot
264dadb4c1
this PR Repla Reviewed-by: Székely, Ond <ond.szekely@t-systems.com> Co-authored-by: proposalbot <proposalbot@otc-service.com> Co-committed-by: proposalbot <proposalbot@otc-service.com>
1.7 KiB
1.7 KiB
- original_name
dds_01_0011.html
Cluster
Each DDS cluster is an independent document database. A sharded cluster consists of a config node, and multiple mongos and shard nodes.
Data read and write requests are forwarded by the 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.
- A driver handles all interactions between your application and the database in a language appropriate to the application. For details, see official documents.
- Each mongos is a single node, but you can provision multiple mongos nodes for load balancing and failovers. A single cluster can contain 2 to 32 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 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 <dds_02_0100>to directly access the shards and the config node. - A three-node replica set cannot be directly upgraded to a cluster.