Function Overview

Document Database Service (DDS) is an easy-to-use MongoDB-compatible database service that is secure, highly available, reliable, and scalable.It provides DB instance creation, scaling, disaster recovery, backup, restoration, monitoring, and alarm reporting functions with just a few clicks on the DDS console. DDS offers three types of instance architectures to suit different scenarios: cluster, replica set, and single node.

DDS has the following features:

① DDS automatically establishes a three-node replica set architecture. It supports fast deployment, high availability (HA) storage, disaster recovery, and failover.

② DDS provides sharded cluster instances comprising a config node paired with multiple shard and dds mongos nodes. These cluster instances can be easily scaled up to enhance read and write performance.

③ DDS lets you back up or restore a database from the management console in just a few clicks.

④ DDS provides performance metrics and you can configure alarm notifications to make it easier to keep abreast of instance statuses.

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 shard nodes, making it easy to handle high concurrency scenarios. In addition, each config node, along with the shard nodes in its cluster, are replicated in triplicate to ensure high availability.

① 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. A single cluster supports 2 to 32 shard nodes.

③ 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 on the management console. You do not need to use native commands.

⑤ You cannot access data on the config or shard nodes directly. You can only manage the data on the shard nodes though the dds mongos nodes.

⑥ If the region where the tenant belongs contains three or more AZs, a DB instance can be deployed across these different AZs. In a DB instance, the dds mongos nodes can be deployed in one or more AZs. The primary, secondary, and hidden config and shard nodes are deployed across three different AZs for disaster recovery.

⑦ Currently, a three-node replica set cannot be directly converted into a cluster.

A replica set consists of a set of mongod processes. It is a collection of nodes that help ensure data redundancy and reliability.

A replica set consists of three nodes: primary, secondary, and hidden. The three-node architecture is set up automatically, and the three nodes automatically synchronize data with each other to ensure data reliability.

• Primary node: Primary nodes are used to process both read and write requests.
• Secondary node: Secondary nodes are used to process read requests only.
• Hidden node: Hidden nodes are used to back up data.

You can perform operations on the primary and secondary nodes. If a primary node becomes faulty, a secondary node takes over and becomes the primary. If the secondary node is unavailable, a hidden node will take the role of the secondary to ensure high availability.

A single node instance, as its name suggests, contains only one node and that node can be accessed directly.

As a supplement to the cluster and replica set architectures, the single-node architecture is useful for R&D, testing, and non-core data storage of enterprises. While not as robust as replica sets, single node architecture can be a less expensive way to visualize O&M and provide elastic scaling.

DDS provides multiple migration schemes to migrate data in different service scenarios:

① Migrating data using DRS.

② Migrating data using mongoexport and mongoimport.

③ Migrating data using mongodump and mongorestore.

DRS is a stable, efficient, easy-to-use cloud service for online database migration.It simplifies data transmission between databases and reduces data transmission costs. You are advised to use DRS to migrate DB instances.

You can scale up the storage space of a DB instance to suit your service requirements.

You can change the DB instance class to meet your service requirements.

DDS allows you to back up databases by configuring an automated backup policy or by creating manual backups. If a database is faulty or data is damaged, you can restore it from backups to ensure data reliability.

You can customize the parameter settings to manage DB engine configurations. DB parameter templates act as a container for engine configuration values that are applied to one or more DB instances.

When creating a DB instance, you can associate a default parameter template or a custom parameter template with the DB instance. After a DB instance is created, you can also change the associated parameter template.

• Default parameter templates
  

      Each default parameter template contains database engine defaults and database system defaults.

• Custom parameter templates
  

      If you need a DB instance with customized parameter settings, you can create a parameter template and change the parameter values as required.

Precautions

• Default parameter templates are unchangeable. When you click their names, you can only view the existing details. If inappropriate settings of a customized parameter template lead to a database startup failure, you can reset the customized parameter template by referring to the settings of the default parameter template.
• After modifying a parameter, you need to view the associated instance status in the instance list. If Pending restart is displayed, you need to restart the instance for the modification to take effect.
• Improper parameter settings in a parameter template may have unintended adverse effects, including degraded performance and system instability. Exercise caution when modifying database parameters and you need to back up data before modifying parameters in a parameter template. Before applying parameter changes to a production DB instance, you should try out these changes on a test DB instance.

Cloud Eye monitors the status of DDS. You can obtain the monitoring metrics of DDS on the management console.

Monitored data requires a period of time for transmission and display. The status of DDS instances displayed on the Cloud Eye page is from about 5 to 10 minutes ago, so the data for a newly created DB instance takes about 5 to 10 minutes to show up on Cloud Eye.

DDS log management allows you to view database-level error logs, slow query logs, and audit logs, helping you analyze root causes of faults.

Tag Management Service (TMS) enables you to use tags on the management console to manage resources. TMS works with other cloud services to manage tags. TMS manages tags globally and other cloud services manage their own tags.

Adding tags to DDS DB instances helps you better identify and manage them. A DB instance can be tagged during or after it is created.

• You are advised to set predefined tags on the TMS console.
• A tag consists of a key and value. You can add only one value for each key.