Tair: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 first. If sufficient resources are available, the shard specifications are changed without impacts on your business. If resources are insufficient, a new node that has the specified specifications is created, and data is synchronized to the new node. Business is switched to the new node at the specified switchover time. The nodes involved in the switchover may experience transient connections.

• Local disk-based instances

  If a private endpoint is allocated to a cluster instance and you want to change the shard configurations of the 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.

• Child instances in a distributed instance

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

  • 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?

• 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.

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

Tair does not allow you to separately upgrade CPU specifications. You can use the following methods to improve the overall CPU performance of an instance:

• 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 types, 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 configurations on the Change Configurations page.

• You can change a cloud disk-based 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 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 become read-only for up to 1 minute and 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 time required for a configuration change is affected by various factors such as the network conditions, the number of business requests, and the data volume. Therefore, the exact duration cannot be estimated.

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

A configuration change does not cause data loss.

After you submit the 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.