Are Services Interrupted During Specification Modification?

Changing the Instance Type

Currently, only the instance type changes listed in the table above are supported. To change the specifications of an instance across different instance types, you are advised to create a new instance, migrate data, and swap the IP addresses of the two instances. For details, see Online Migration Between Instances.

For details about the commands supported by different types of instances, see Command Compatibility.

Changing the Instance Specifications

• Specifications change details

  Table 2 Instance specifications change details

  Cache Engine	Single-Node	Master/Standby	Redis Cluster	Proxy Cluster	Read/Write Splitting
  Redis 3.0	Scale-up and scale-down	Scale-up and scale-down	-	Scale-up	-
  Redis 4.0	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change	Scale-up, scale-down, and replica quantity change	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change
  Redis 5.0	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change	Scale-up, scale-down, and replica quantity change	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change
  Redis 6.0 Basic Edition	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change	Scale-up, scale-down, and replica quantity change	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change
  Redis 6.0 Enterprise Edition	-	Scale-up and scale-down	-	-	-
  Redis 7.0	Scale-up and scale-down	Scale-up, scale-down, and replica quantity change	Scale-up, scale-down, and replica quantity change	-	-
  Memcached	Scale-up and scale-down	Scale-up and scale-down	-	-	-

• Specifications change impacts

  Table 3 Specifications change impacts

  Instance Type	Specifications Change Type	Impact
  Single-node, read/write splitting, and master/standby	Scale-up or scale-down	During the scale-up, the instance cannot be connected for several seconds and remains read-only for about 1 minute. During the scale-down, the instance will not be disconnected. A DCS Redis 3.0 instance will be disconnected for several seconds and remain read-only for 5 to 30 minutes. A DCS Redis Enterprise-Edition instance will be disconnected for several seconds and remain read-only for about 1 minute. In a scale-up, only the memory of the instance is increased. The CPU processing capability is not improved. Single-node DCS instances do not support data persistence. Specifications change may compromise data reliability. After the specifications change, check whether the data is complete and import data if required. If there is important data, use a migration tool to migrate the data to other instances for backup. The backup records of master/standby and read/write splitting instances before scale-down cannot be used after scale-down. If necessary, download the backup file in advance or back up the data again after scale-down.
  Proxy Cluster and Redis Cluster	Scale-up or scale-down	Horizontal scaling by adding shards: The server does not proactively disconnect from the instance but will consume CPU resources, deteriorating performance by up to 20%. When the number of shards increases, data nodes are added. Data is automatically balanced to the new data nodes, increasing the access latency. Horizontal scaling by reducing shards: When the number of shards decreases, nodes are deleted. Before scaling down a Redis Cluster instance, ensure that the deleted nodes are not directly referenced by your application, to prevent service access exceptions. Deleting nodes will cause intermittent disconnections. Ensure that your client application has a reconnection mechanism and can handle exceptions. Otherwise, you may need to restart the client application after the change. Vertical scaling by increasing the shard capacity without changing the number of shards: If the memory of the VM accommodating the node is insufficient, the node will be migrated. During the migration, service connections will be intermittently interrupted and the node will become read-only. Increasing the shard capacity when the VM memory is sufficient does not affect services. NOTE: Cluster DCS Redis 3.0 instances cannot be vertically scaled. Vertical scaling by reducing the shard capacity without changing the number of shards: There is no impact. To scale down an instance, ensure that the used memory of each node is less than 70% of the node's maximum memory on the new instance. Otherwise, the change will be prohibited. During the specifications change, data may be migrated, which increases the access latency. Ensure that the client can properly process MOVED and ASK commands. Otherwise, requests will fail. If a large amount of data is written to the node during the instance specifications change, the node memory will be used up. As a result, the change will fail. Before changing the instance specifications, check for big keys through Cache Analysis. Redis has a limit on key migration. If the instance has any single key greater than or equal to 512 MB, specifications change will fail when big key migration between nodes times out. A bigger key results in a higher probability of the failure. Before scaling a Redis Cluster instance, ensure that automatic cluster topology refresh is enabled. If it is disabled, you will need to restart the client after the scaling. For details about how to enable automatic cluster topology refresh on a Lettuce client, see examples in Connecting to Redis on Lettuce (Java). Backup records before the specifications change cannot be used after the change. If necessary, download the backup file in advance or back up data again after the change.
  Master/Standby, read/write splitting, and Redis Cluster instances	Replica quantity change	Before adding or deleting replicas for a Redis Cluster instance, ensure that automatic cluster topology refresh is enabled. If it is disabled, you will need to restart the client after the change. For details about how to enable automatic cluster topology refresh on a Lettuce client, see examples in Connecting to Redis on Lettuce (Java). Deleting replicas interrupts connections. If your application cannot reconnect to Redis or handle exceptions, you may need to restart the application after the change. Adding replicas does not interrupt connections. If the number of replicas is already the minimum supported by the instance, you can no longer delete replicas.