All Products
Search
Document Center

ApsaraDB for Redis:Change the configurations of an instance

Last Updated:Jun 18, 2024

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

If you change the configurations of a pay-as-you-go instance, you are charged based on the new specifications. If you change the configurations of a subscription instance, you are charged or are refunded the difference in cost based on whether you upgrade or downgrade the configurations.

For more information about the billing rules for configuration changes and the refund rules for configuration downgrades, see Configuration changes.

Change process

Local disk-based instances

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.

image

Cloud disk-based instances

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

image

Impacts of configuration changes

Local disk-based and cloud disk-based standard instances

  • When you change the configurations of an instance, the instance may experience one or two transient connections that each lasts up to 30 seconds.

  • To synchronize incremental data from the original instance to the new instance and prevent dual writes caused by Domain Name System (DNS) caching, the instance stays in the read-only state for up to 1 minute during the configuration change. If a large amount of data is written to the instance, the instance may remain in the read-only state for an extended period of time. Therefore, we recommend that you perform the configuration change during off-peak hours.

  • To ensure higher performance and stability, the system updates the instance to the latest minor version during the configuration change. Minor versions are designed to be forward compatible, which eliminates compatibility issues.

  • If you change the architecture of an instance, such as switching between the standard, cluster, and read/write splitting architectures, the following impacts may occur:

Cloud disk-based cluster instances

If you change the specifications of a shard, a master-replica switchover may occur. During the switchover, the shard may experience a transient connection.

Limits

Limits on configuration changes for different connection modes

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

Limits on configuration changes of distributed instances

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

Limits on configuration changes of ESSD/SSD-based instances

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

Feature matrix for configuration changes

The configuration change options that are supported on the Upgrade/Downgrade page (Upgrade or Downgrade page for subscription instances) vary based on the deployment method and architecture.

The following section describes the symbols that are used in the following tables:

  • ️✔️ indicates that you can perform operations on the Upgrade/Downgrade page.

  • ⭕️️ indicates that you cannot perform operations on the Upgrade/Downgrade page. For specific operation methods, see the note below the table.

  • ❌ indicates that this type of configuration change is not supported.

  • ➖ indicates that this type of configuration change is not involved.

Deployment type/Change option

Switch to the cluster architecture

Switch to the read/write splitting architecture

Switch to the standard architecture

Change shard specifications

Change the number of shards

Change the number of read replicas

Classic deployment

✔️

✔️

✔️

✔️

✔️

✔️

Cloud-native standard architecture

✔️

⭕️1

✔️

Cloud-native cluster architecture

⭕️2

✔️3

✔️

⭕️4

Cloud-native read/write splitting architecture

⭕️5

⭕️6

✔️

⭕️7

Note

1To switch an instance from the cloud-native standard architecture to the read/write splitting architecture, enable read/write splitting for the instance on the Read/Write Splitting Settings page. For more information, see Enable read/write splitting.

2To switch an instance from the cloud-native cluster architecture to the read/write splitting architecture, the instance must run in proxy mode. Change the instance to a standard instance, and then enable read/write splitting for the instance on the Read/Write Splitting Settings page.

3To switch an instance from the cloud-native cluster architecture to the standard architecture, the instance must run in proxy mode. The direct connection mode is not supported.

4To change the number of shards for a cloud-native cluster instance, add or remove shards. For more information, see Adjust the number of shards for an instance.

5To switch an instance from the cloud-native read/write splitting architecture to the cluster architecture, disable read/write splitting for the instance and then change the architecture on the Upgrade/Downgrade page.

6To switch an instance from the cloud-native read/write splitting architecture to the standard architecture, disable read/write splitting on the Read/Write Splitting Settings page. For more information, see Enable read/write splitting.

7To change the number of read replicas for a cloud-native read/write splitting instance, adjust the number of read replicas on the Read/Write Splitting Settings page. For more information, see Enable read/write splitting.

Procedure

  1. 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 that you want to manage resides. Then, find the instance and click the instance ID.

  2. In the upper-right corner of the instance details page, choose Scale Up/Down > Change Shard Capacity.

  3. On the Upgrade/Downgrade page, make required configuration changes and click Buy Now.

    Important

    When you change the configurations of an instance, we recommend that you set the Switching Time parameter to Switch Within Maintenance Window. This way, the instance configurations are changed in the next maintenance window. For more information, see Configure a maintenance window. Before the switchover task is executed for the instance, you can change the switching time at any time. In the left-side navigation pane, click Task Center. On the page that appears, find the switchover task for the instance and click Modify switching time in the Actions column. Then, change the switching time to allow the task to be immediately executed.

  4. Complete the payment.

FAQ

Why does a configuration change fail?

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

Does the endpoint of an instance change after a configuration change? Do I need to modify the application code?

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.

Can I change the configurations of my ApsaraDB for Redis Enhanced Edition (Tair) instance across storage types?

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

Can I separately improve the CPU performance of an instance?

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.

Can I directly upgrade a local disk-based instance to a cloud disk-based instance?

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.

How do I change a cluster instance to a standard instance?

  • You can change a local disk-based 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 disk-based cluster instance in proxy mode to a standard instance. Cluster instances in direct connection mode cannot be changed to standard instances.

How do I change a high-availability master-replica instance to a standalone instance?

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

Do I need to suspend read and write operations when I change the configurations of an instance?

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.

When I change a standard instance to a cluster instance or adjust the number of shards for a cluster instance, is data automatically migrated to each shard?

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.

How long does it take to perform a configuration change?

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 image.png icon in the upper-right corner of the Instance Information page to check the progress of the configuration change.

image.png

Does a configuration change cause data loss?

A configuration change does not cause data loss.

Does a configuration change results in the loss of backup sets?

A configuration change does not result in the loss of backup sets. However, if you remove shards from a local disk-based 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.

Why is an instance in the Changing Configuration state after I set the switchover time to Switch Within Maintenance Window and submit a configuration change request?

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.

The "The direct custins can not trans to normal custins" error message appears when I change the configurations of an instance. What do I do?

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.

Related API operations

API operation

Description

ModifyInstanceSpec

Changes the configurations of an ApsaraDB for Redis instance.