Function Overview

Data in DCS instances can be backed up to Object Storage Service (OBS). If a DCS instance becomes faulty, data in the instance can be restored from the backup, so that service continuity is not affected.

Both automatic backup and manual backup are supported.

Only the data of master/standby, cluster, and read/write splitting DCS Redis instances can be backed up and restored, while those of single-node instances cannot.

You can create run log files on the DCS console to collect run logs of DCS Redis 4.0 and later instances within a specified time range. After the logs are collected, you can download the log files to view the logs.

Cache analysis: By performing big key analysis and hot key analysis, you will have a picture of keys that occupy a large space and those that are frequently accessed.

Slow queries: Redis records queries that exceed a specified execution time. You can view slow query logs on the DCS console to identify performance issues.

Instance diagnosis: If a fault or performance issue occurs, you can use this function to learn about the cause and impact of the issue and how to handle it.

You can access a DCS instance over a public network using the instance public IP address. DCS has the following restrictions on public access:

Only password-protected DCS Redis 3.0 instances support public access. You can enable or disable SSL for public access. You are advised to download a CA certificate in advance and use it to verify the certificate of a DCS instance for security purposes.

DCS Redis 4.0 and later instances do not support direct public access. Single-node, master/standby, read/write splitting, and Proxy Cluster instances with password-protected enabled support public access through Elastic Load Balance (ELB). Redis Cluster instances do not support public access.

DCS Memcached instances do not support public access. To access a DCS Memcached instance, you must use an ECS that is in the same VPC as the DCS instance. In the application development and debugging phase, you can also use an SSH agent to access DCS Memcached instances in the local environment.

You can use security groups or whitelists to control access to your DCS instances. Only clients that meet the requirements can access your DCS instances.

DCS helps you control access to your DCS instances in the following modes:

To control access to DCS Redis 3.0 and Redis 6.0 professional edition instances, you can use security groups. Whitelists are not supported.

To control access to DCS Redis 4.0/5.0/6.0 basic edition instances, you can use whitelists. Security groups are not supported.

You can modify the specifications of a DCS Redis or Memcached instance to meet changing service requirements. In addition to the cache capacity, you can also change the instance type of some instances.

For example, you can change a master/standby DCS Redis 4.0/5.0 instance of 2 GB to a Proxy Cluster instance with another cache size.

Different Redis versions use different underlying architectures. The Redis version used by a DCS instance cannot be changed once the instance is created. For example, you cannot change a DCS Redis 3.0 instance to Redis 4.0 or 5.0.

If your service requires the features of higher Redis versions, create a DCS Redis instance of a higher version and then migrate data from the old instance to the new one.

Once an instance is created, its VPC and subnet cannot be changed. If you want to use a different set of VPC and subnet, create an instance and specify a desired set of VPC and subnet, and then migrate data from the old instance to the new one.

DCS provides read/write splitting to meet high-concurrency read/write requirements.

Currently, read/write splitting is supported only by Redis Cluster DCS instances,  read/write splitting DCS instances, and master/standby DCS Redis instances.

To implement read/write splitting without client configurations, use read/write splitting instances.

Currently, DCS does not support cross-region multi-active because Redis does not have a mature active-active solution. Active-active is different from disaster recovery or master/standby high availability.

Redis active-active across clouds or regions cannot be achieved because the customized REdis Serialization Protocols (RESP) are not unified. If active-active is required, it can be implemented through dual-write on the application end.

DCS for Redis provides the following two migration modes:

Importing data from backup files: Download the source Redis data and then upload the data to an OBS bucket in the same region as the destination DCS Redis instance. DCS will read the backup data from the OBS bucket and migrate the data into the destination instance. This migration mode can be used for migrating data from other Redis vendors or self-hosted Redis to HUAWEI CLOUD DCS for Redis.

Migrating data online: If the source and destination instances are interconnected and the SYNC and PSYNC commands are supported in the source instance, data can be migrated online in full or incrementally from the source to the destination.

Monitoring is key to ensuring DCS instance reliability, availability, and performance, and determining instance resource usage. Cloud Eye is a monitoring service that can capture the running status of your DCS instances. You can use Cloud Eye to automatically monitor DCS instances in real time and manage alarms and notifications, so that you can keep track of DCS performance metrics.

Cloud Trace Service (CTS) records operations on your cloud resources, allowing you to query, audit, and backtrack resource operation requests initiated from the management console or open APIs as well as responses to these requests.

DCS provides REST APIs that support HTTP/HTTPS methods. You can call APIs to create, delete, and modify instances.