:Change the configurations of an instance

After you submit a configuration change request, the status of the instance immediately changes to Changing Configuration. Tair creates a new instance and automatically synchronizes data from the original instance to the new instance. After data synchronization is complete, Tair 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. Tair evaluates the resources. If resources are sufficient, 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 classic 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 classic 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 switch a child instance 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 Enterprise SSD (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.

  Before you change the configurations, we recommend that you identify and delete large keys from the instance. 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 used 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 2 GB is already used, you can downgrade the instance to a standard DRAM-based instance that has a storage capacity of 4 GB.

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

Tair does not support configuration changes between different storage types, such as memory, persistent memory, and ESSDs.

Tair 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 classic instance to a cloud-native instance.

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

• You can change a classic cluster instance to a standard instance by changing the configurations of the instance on the Upgrade/Downgrade 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 a cloud-native cluster instance in proxy mode to a standard instance. Cluster instances in direct connection mode cannot be changed 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 standalone instance, and then use Data Transmission Service (DTS) to migrate data from the high-availability instance to the 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, data is automatically migrated to each shard during the configuration change. 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.

A configuration change does not result in the loss of backup sets. However, if you remove shards from a classic cluster instance or change the instance to a standard instance, the mappings between historical backup sets and instance nodes may change.

In this scenario, you can search for historical backup sets by backup point in time or ID.

To restore your data from a backup set, you can download the backup set, which is generally a Redis Database (RDB) file. Then, parse and import the file to the new instance.

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.