Are Services Interrupted During Specification Modification?

Change of the Instance Type

Any instance type changes not listed in the preceding table are not supported. To modify specifications while changing the instance type, see IP Switching.

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

Scaling

• Scaling options

  Table 2 Scaling options supported by different instances

  Cache Engine	Single-Node	Master/Standby	Redis Cluster	Proxy Cluster	Read/Write Splitting
  Redis 3.0	Scaling up/down	Scaling up/down	Scaling up/down	Scaling up	-
  Redis 4.0	Scaling up/down	Scaling up/down, out/in	Scaling up/down, out/in	Scaling up/down	Scaling up/down, out/in
  Redis 5.0	Scaling up/down	Scaling up/down, out/in	Scaling up/down, out/in	Scaling up/down	Scaling up/down, out/in
  Redis 6.0 basic edition	Scaling up/down	Scaling up/down	Scaling up/down, out/in	-	-
  Redis 6.0 professional editions	-	No change is supported.	-	-	-
  Memcached	Scaling up/down	Scaling up/down	-	-	-

  

  • If the reserved memory of a DCS Redis 3.0 or Memcached instance is insufficient, the modification may fail when the memory is used up. For details, see Reserved Memory.
  • Change the replica quantity and capacity separately.
• Impact of scaling

  Table 3 Impact of scaling

  Instance Type	Scaling Type	Impact
  Single-node, read/write splitting, and master/standby	Scaling up/down	During scaling up, a DCS Redis 4.0/5.0/6.0 basic edition instance will be disconnected for several seconds and remain read-only for about 1 minute. During scaling down, connections will not be interrupted. A DCS Redis 3.0 instance will be disconnected for several seconds 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. Single-node DCS instances do not support data persistence. Scaling may compromise data reliability. After scaling, 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. For master/standby and read/write splitting instances, backup records created 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	Scaling up/down	During scaling up and scaling down that does not involve a shard quantity decrease, connections will not be interrupted, but CPU resources will be occupied, decreasing performance by up to 20%. During scaling up and scaling down that involves a shard quantity decrease, nodes will be deleted, and connections will be interrupted. If your application cannot reconnect to Redis or handle exceptions, you may need to restart the application after scaling. If the shard quantity increases, new Redis Server nodes are added, and data is automatically balanced to the new nodes. If the shard quantity decreases, nodes will be deleted. Before scaling down a Redis Cluster instance, ensure that the deleted nodes are not directly referenced in your application, to prevent service access exceptions. To scale down an instance, ensure that the used memory of each node is less than 70% of the maximum memory per node of the new flavor. Scaling involves data migration, which increases access latency. For a Redis Cluster instance, ensure that the client can properly process the MOVED and ASK commands. Otherwise, requests will fail. If the memory becomes full during scaling due to a large amount of data being written, scaling will fail. Before scaling, check for big keys through Cache Analysis. Redis has a limit on key migration. If the instance has any single key greater than 512 MB, scaling will fail when big key migration between nodes times out. The bigger the key, the more likely the migration will fail. Before scaling up or down a Redis Cluster instance, ensure that automated cluster topology refresh is enabled if you use Lettuce. If it is disabled, you will need to restart the client after scaling. For details about how to enable automated refresh, see an example of using Lettuce to connect to a Redis Cluster instance. Backup records created before scaling cannot be used. If necessary, download the backup file in advance or back up the data again after scaling.
  Master/standby, read/write splitting, and Redis Cluster instances	Scaling out/in (replica quantity change)	Before scaling out or in a Redis Cluster instance, ensure that automated cluster topology refresh is enabled if you use Lettuce. If it is disabled, you will need to restart the client after scaling. For details about how to enable automated refresh, see an example of using Lettuce to connect to a Redis Cluster instance. Deleting replicas interrupts connections. If your application cannot reconnect to Redis or handle exceptions, you may need to restart the application after scaling. 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.