Change the configurations of an instance - ApsaraDB for Redis

ApsaraDB for Redis allows you to change the configurations of instances. You can change configurations such as the architecture and specifications of an instance to meet different performance and capacity requirements.

Billing

For more information, see Configuration changes.

Change processes and impacts

Instance type	Change process and impact
Classic instances Cloud-native instances that use the standard architecture	Figure 1. Process of changing the configurations of a classic instance The cluster architecture imposes requirements on Lua scripts. After you change a non-cluster instance into a cluster instance, the Lua scripts may be lost because the script content does not meet the requirements. You must back up the Lua scripts in advance. For more information, see Limits on commands supported by cluster instances. If you change the configurations of an instance, the instance may experience one or two transient connections that last for less than 30 seconds. For the Lettuce client, connection disruptions can last anywhere from 2 to 10 minutes. Important When you change the configurations of an instance, we recommend that you set the Switching Time parameter to Switch Within Maintenance Window. In this case, the instance configurations are changed and transient connections occur in the next maintenance window. To synchronize incremental data from the original instance to the new instance and prevent dual writes caused by the Domain Name System (DNS) cache, the instance becomes read-only for less than 1 minute during the configuration change. This ensures data consistency between the new and the original instances. To ensure higher performance and stability, the system updates the minor version of an instance to the latest version during the configuration change.
Cloud-native instances that use the cluster architecture	During the configuration change, ApsaraDB for Redis migrates slots, for example, to the newly added data shards. This can help implement imperceptible scaling where the latency remains under 100 milliseconds.

Note After you change the configurations of an instance, the instance information that includes the instance ID, endpoints, data, whitelists, and existing accounts and their corresponding passwords does not change.

Limits

Instance type	Limits
Classic instances	Before you change a non-cluster instance into a cluster instance, you must evaluate how the command limits of cluster instances affect your workloads. For more information, see Limits on commands supported by cluster instances. If you change the architecture of an instance (for example, from standard to cluster), the existing alert settings become invalid and the data flashback feature is disabled. To continue using alerts, you must reconfigure alert settings. For more information, see Alert settings. To continue using data flashback, you must re-enable the feature. For more information, see Use data flashback to restore data by point in time. If a private endpoint is allocated to a cluster instance and you want to change the number of data shards for the instance, you can only double the current number of data shards. For more information about private endpoints, see Enable the direct connection mode. For example, if the original instance has two data shards, you can scale the instance only to four data shards. You cannot directly scale the instance to eight data shards. If you want to scale the instance from two data shards to eight data shards, use one of the following methods: Scale the instance from two data shards to four data shards. Then, scale the instance from four data shards to eight data shards. Release the private endpoint, and then directly scale the instance to eight shards. For more information, see Release a private endpoint for an ApsaraDB for Redis instance.
Cloud-native instances that use the cluster architecture	You cannot change the number and specifications of the data shards in the instance at the same time. An instance can contain 2 to 256 data shards. You can add or reduce up to 64 data shards each time. The specifications of the data shards that you want to add are the same as those of existing data shards and cannot be modified. For more information, see Adjust the number of shards for an ApsaraDB for Redis cloud-native instance.
Child instances in a distributed instance	You cannot change the architecture of a child instance, for example, from cluster to standard. To change the configurations of a child instance in a distributed instance, you must change the configurations of all the other child instances in the distributed instance in the same way. Otherwise, performance or capacity issues may occur. You can only double the current number of data shards for a child instance. For example, if the original instance has two data shards, you can scale the instance only to four data shards. You cannot directly scale the instance to eight data shards. Note If you want to scale the instance from two shards to eight shards, you can scale the instance from two shards to four shards. Then, scale the instance from four shards to eight shards.

When you downgrade the configurations of an instance, note that 80% of the memory capacity of the new instance must be greater than the amount of occupied memory in the original instance. Otherwise, the instance cannot be downgraded. For example, if the original instance is a standard DRAM-based instance that has a storage capacity of 8 GB and has 2 GB used, you can change the configurations of the instance to a standard DRAM-based instance that has a storage capacity of 4 GB.

Manually change the configurations of an instance

Log on to the ApsaraDB for Redis console and go to the Instances page. In the top navigation bar, select the region in which the instance is deployed. Then, find the instance and click its ID.

Perform the corresponding operations described in the following table based on the billing method of your instance.

Billing method	Description
Pay-as-you-go	In the upper-right corner of the page, click Change Configurations . On the Upgrade/Downgrade page, make the required configuration changes and click Buy Now.
Subscription	In the upper-right corner of the page, click Upgrade. On the Upgrade/Downgrade page, make required configuration changes and click Buy Now.

Warning

If large keys exist in the original instance, the configuration change may fail.
In this case, we recommend that you identify and delete large keys from the instance before you perform the configuration change. For more information about how to identify large keys, see Use the real-time key statistics feature or Use the offline key analysis feature.
If you want to change a non-cluster instance into a cluster instance, or change the instance type of a cluster instance without changing its architecture, take note of the following items:
- You must read and confirm the related limits of cluster instances. For more information about these limits, see Limits on commands supported by cluster instances.
- If the original instance contains Lua scripts, back up the Lua scripts in advance and select Force Upgrade during the configuration change. This way, you can complete the configuration change.
  If you select forceful configuration change, the Lua scripts are deleted from the original instance.
When you change the configurations of an instance, we recommend that you set the Switching Time parameter to Switch Within Maintenance Window. In this case, the instance configurations are changed in the next maintenance window. For more information, see Set a maintenance window.

Complete the payment.

Related API operations

API operation	Description
ModifyInstanceSpec	Changes the configurations of an ApsaraDB for Redis instance.