ApsaraDB for Redis:Change the configurations of an instance

After you submit a configuration change request, the status of the instance immediately changes to Changing Configuration. Redis creates a new instance and automatically synchronizes data from the original instance to the new instance. After data synchronization is complete, Redis switches business to the new instance at the specified switchover time. During the switchover, the instance may experience one or two transient connections that each lasts up to 30 seconds. After the switchover is complete, the instance is in the Running state and the configuration change is complete.

After you submit a request to change the shard specifications, the status of the instance immediately changes to Changing Configuration. Redis evaluates the resources. If sufficient resources are available, the shard specifications are changed without impacts on your business. If resources are insufficient, a new shard that has the specified specifications is created, and data is synchronized to the new shard. Business is switched to the new shard at the specified switchover time. The shards involved in the switchover may experience transient connections.

• You can change cloud-native standard or read/write splitting instances to cluster instances only in proxy mode.

• You cannot change cloud-native cluster instances in direct connection mode to cluster instances in proxy mode, standard instances, or read/write splitting instances.

• If a private endpoint is allocated to a local disk-based cluster instance, you cannot change the instance to a standard or read/write splitting instance. To change the instance architecture, you must release the private endpoint of the instance.

• If a private endpoint is allocated to a local disk-based cluster instance, you cannot change the number of shards and the shard specifications at the same time. For more information, see Why am I unable to change the configurations of a classic (local disk-based) cluster instance?

• You cannot change the architecture of a child instance. For example, you cannot change the architecture from the cluster architecture to the standard architecture.

• All child instances in a distributed instance must have the same configurations. Otherwise, performance or capacity issues may occur.

• When you change the configurations of a cluster instance, you can adjust either the shard specifications or the number of shards. For more information, see Why am I unable to change the configurations of a classic (local disk-based) cluster instance?

• You can increase the storage capacity of ESSD-based instances in increments of at least 10 GB. However, you cannot decrease the storage capacity of ESSD-based instances.

• You cannot change the architecture of SSD-based instances.

• 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 change the configurations. For more information about how to identify large keys, see Use the offline key analysis feature.

• When you downgrade the configurations of an instance, take 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 downgrade the instance to a standard DRAM-based instance that has a storage capacity of 4 GB.

Regardless of whether you change a standard instance to a cluster instance or change a standalone instance to a master-replica instance, the instance information remains unchanged. The information includes the instance ID, endpoints, data, whitelists, and existing accounts and their corresponding passwords.

ApsaraDB for Redis Enhanced Edition (Tair) does not support configuration changes between different storage types, such as memory, persistent memory, and enhanced SSDs (ESSDs).

ApsaraDB for Redis does not allow separate upgrades of CPU specifications. To improve the overall CPU performance of an instance, you can use one of the following methods:

• Change a standard instance to a cluster or read/write splitting instance.

• Increase the number of read replicas for a read/write splitting instance.

• Increase the number of shards for a cluster instance.

For more information, see How do I upgrade the CPU specifications of an ApsaraDB for Redis instance?

For more information about instance specifications, see Overview.

You cannot directly upgrade a local disk-based instance to a cloud disk-based instance.

If you want to upgrade a local disk-based instance to a cloud-disk based instance, separately purchase a cloud disk-based instance, and then migrate data from the local disk-based instance to the cloud disk-based instance. For more information, see Migrate data between ApsaraDB for Redis instances.

• You can change a local disk-based cluster instance to a standard instance by changing the configurations of the instance on the Change Configurations page.

  However, if a private endpoint is allocated to the instance, you must release the private endpoint before you change the configurations of the instance. After the configuration change, you cannot apply for a private endpoint for the instance. Private endpoints are not required for standard instances.

• You can change cloud disk-based cluster instances in proxy mode to cloud-native standard instances. You cannot change cluster instances in direct connection mode to standard instances.

You cannot change a high-availability instance to a standalone instance because standalone instances do not ensure data reliability.

If you want to change a high-availability instance to a standalone instance, separately purchase a high-availability instance, and use Data Transmission Service (DTS) to migrate data from the high-availability instance to a standalone instance. For more information, see Migrate data between ApsaraDB for Redis instances.

No, you do not need to suspend read and write operations during the configuration change. However, the instance may be in the read-only state for up to 1 minute and may experience one or two transient connections that each lasts up to 30 seconds. We recommend that you change the configurations and perform switchover during off-peak hours. For more information, see Impacts of configuration changes.

Yes. When you change a standard instance to a cluster instance or adjust the number of shards for a cluster instance, data is automatically migrated in the background and evenly distributed across shards.

The exact duration cannot be estimated because the time required for a configuration change varies based on various factors, such as the network conditions, the number of business requests, and the data volume.

You can click the icon in the upper-right corner of the Instance Information page to check the progress of the configuration change.

A configuration change does not cause data loss.

After you submit a configuration change request, the status of the instance immediately changes to Changing Configuration. During this phase, the system executes the required preparatory tasks for the configuration change, such as applying for resources and synchronizing data. No switchover is performed and the instance can run as expected.

If you change a classic cluster instance that has a private endpoint to a standard or read/write splitting instance, the "The direct custins can not trans to normal custins" error message appears. This is because you cannot change the architecture of classic cluster instances that have private endpoints. To change the architecture, you must release the private endpoints.