Modifying DCS Instance Specifications

Change of the Instance Type

• Supported instance type changes:
  • From single-node to master/standby: Supported by Redis 3.0 and Memcached, and not by Redis 4.0 and 5.0.
  • From master/standby to Proxy Cluster: Supported by Redis 3.0, and not by Redis 4.0 and 5.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.

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 up
  Redis 4.0	Scaling up/down	Scaling up/down	Scaling up/down	N/A
  Redis 5.0	Scaling up/down	Scaling up/down	Scaling up/down	N/A
  Memcached	Scaling up/down	Scaling up/down	N/A	N/A

  

  If the reserved memory of a DCS Redis 3.0 or Memcached instance is insufficient, the scaling may fail when the memory is used up.

• Impact of scaling:
  • Single-node and master/standby
    • A DCS Redis 4.0 or 5.0 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. If there is important data, use a migration tool to migrate the data to other instances for backup.
    • Backup records of master/standby instances cannot be restored 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.
    • 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.
    • Before scaling, perform cache analysis to ensure that no big keys (≥ 512 MB) exist in the instance. Otherwise, scaling may fail.
    • Backup records created before scaling cannot be restored.

Procedure

1. Log in to the DCS console.
2. Click in the upper left corner and select a region and a project.
3. In the navigation pane, choose Cache Manager.

4. Choose More > Modify Specifications in the row containing the DCS instance.
5. On the Modify Specifications page, select the desired specification and click Next.
6. Click Submit.

   On the displayed Background Tasks page, 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.