Modifying DCS Instance Specifications
On the DCS console, you can scale a DCS Redis instance to a larger or smaller capacity.
- Modify instance specifications during off-peak hours. If the modification failed in peak hours (for example, when memory or CPU usage is over 90% or write traffic surges), try again during off-peak hours.
- You can only change the instance type of single-node or master/standby DCS Redis 3.0 instances.
- If your DCS instances are too old to support scaling, contact technical support to upgrade the instances.
- Services may be interrupted for seconds during the modification. Therefore, services connected to Redis must support reconnection.
- Modifying instance specifications does not affect the connection address, password, data, security group, and whitelist configurations of the instance.
Change of the Instance Type
- Supported instance type changes:
- From single-node to master/standby: Supported by Redis 3.0, and not by Redis 4.0/5.0.
- From master/standby to Proxy Cluster: Supported by Redis 3.0, and not by Redis 4.0/5.0/6.0.
If the data of a master/standby DCS Redis 3.0 instance is stored in multiple databases, or in non-DB0 databases, the instance cannot be changed to the Proxy Cluster type. A master/standby instance can be changed to the Proxy Cluster type only if its data is stored only on DB0.
- From cluster types to other types: Not supported.
- Impact of instance type changes:
- From single-node to master/standby for a DCS Redis 3.0 instance:
The instance cannot be connected for several seconds and remains read-only for about 1 minute.
- From master/standby to Proxy Cluster for a DCS Redis 3.0 instance:
The instance cannot be connected and remains read-only for 5 to 30 minutes.
- From single-node to master/standby for a DCS Redis 3.0 instance:
Scaling
- The following table lists scaling options supported by different DCS instances.
Table 1 Scaling options supported by different DCS instances Cache Engine
Single-Node
Master/Standby
Redis Cluster
Proxy Cluster
Redis 3.0
Scaling up/down
Scaling up/down
N/A
Scaling out
Redis 4.0/5.0
Scaling up/down
Scaling up/down and replica quantity change
Scaling up/down, out/in, and replica quantity change
Scaling up/down and out/in
Redis 6.0
Scaling up/down
Scaling up/down
Scaling up/down, out/in, and replica quantity change
N/A
If the reserved memory of a DCS Redis 3.0 instance is insufficient, the scaling may fail when the memory is used up.
Change the replica quantity and capacity separately.
- Impact of scaling:
- Single-node and master/standby
- A DCS Redis 4.0 or later instance will be disconnected for several seconds and remain read-only for about 1 minute.
- A DCS Redis 3.0 instance will be disconnected and remain read-only for 5 to 30 minutes.
- For scaling up, only the memory of the instance is expanded. The CPU processing capability is not improved.
- Data of single-node instances may be lost because they do not support data persistence. After scaling, check whether the data is complete and import data if required.
- Backup records of master/standby instances cannot be used after scaling down.
- Cluster
- If the shard quantity is not decreased, the instance can always be connected, but the CPU usage will increase, compromising performance by up to 20%, and the latency will increase during data migration.
- During scaling up, new Redis Server nodes are added, and data is automatically balanced to the new nodes.
- Nodes will be deleted if the shard quantity decreases. To prevent disconnection, ensure that the deleted nodes are not directly referenced in your application.
- Ensure that the used memory of each node is less than 70% of the maximum memory per node of the new flavor. Otherwise, you cannot perform the scale-in.
- If the memory becomes full during scaling due to a large amount of data being written, scaling will fail. Modify specifications during off-peak hours.
- Scaling involves data migration. The latency for accessing the key being migrated increases. For a Redis Cluster instance, ensure that the client can properly process the MOVED and ASK commands. Otherwise, requests will fail.
- Backup records created before scaling cannot be restored.
- Single-node and master/standby
- Notes on changing the number of replicas of a DCS Redis instance:
Deleting replicas interrupts connections. If your application cannot reconnect to Redis or handle exceptions, you need to restart the application after scaling.
Procedure
- Log in to the DCS console.
- Click in the upper left corner and select a region and a project.
- In the navigation pane, choose Cache Manager.
- Choose More > Modify Specifications in the row containing the DCS instance.
- On the Modify Specifications page, select the desired specification.
For a master/standby or Redis Cluster DCS Redis 4.0 or later instance, you can choose to change by specification or replica quantity.
- Set Apply Change to Now or During maintenance.
Select During maintenance if the modification interrupts connections.
Table 2 Scenarios where specification modification interrupts connections Change
When Connections Are Interrupted
Scaling up a single-node or master/standby instance
Memory is increased from a size smaller than 8 GB to 8 GB or larger.
Scaling down a Proxy Cluster and Redis Cluster instance
The number of shards is decreased.
Deleting replicas
Replicas are deleted from a master/standby or Redis Cluster instance.
- If the modification does not interrupt connections, it will be applied immediately even if you select During maintenance.
- The modification cannot be withdrawn once submitted. To reschedule a modification, you can change the maintenance window. The maintenance window can be changed up to three times.
- Modifications on DCS Redis 3.0 instances can only be applied immediately.
- If you apply the change during maintenance, the change starts at any time within the maintenance window, rather than at the start time of the window.
- If a large amount of data needs to be migrated when you scale down a cluster instance, the operation may not be completed within the maintenance window.
- Click Next. In the dialog box that is displayed, click Yes.
- Click Submit to start modifying the DCS instance.
You can go to Background Tasks page to view the modification status. For more information, see Viewing Background Tasks.
Specification modification of a single-node or master/standby DCS instance takes about 5 to 30 minutes to complete, while that of a cluster DCS instance takes a longer time. After an instance is successfully modified, it changes to the Running state.- If the specification modification of a single-node DCS instance fails, the instance is temporarily unavailable for use. The specification remains unchanged. Some management operations (such as parameter configuration and specification modification) are temporarily not supported. After the specification modification is completed in the backend, the instance changes to the new specification and becomes available for use again.
- If the specification modification of a master/standby or cluster DCS instance fails, the instance is still available for use with its original specifications. Some management operations (such as parameter configuration, backup, restoration, and specification modification) are temporarily not supported. Remember not to read or write more data than allowed by the original specifications; otherwise, data loss may occur.
- After the specification modification is successful, the new specification of the instance takes effect.
- If the error "DCS.4104 The DCS instance is recovering from an internal fault. Please try again." is displayed, contact O&M personnel.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot