standard to cluster,cluster to standard,read/write splitting,enable read/write splitting - Tair (Redis® OSS-Compatible)

Tair (Redis OSS-compatible) lets you change the instance architecture between standard (master-replica) and cluster.

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 from standard (master-replica) to cluster

Impacts

The endpoints, accounts, passwords, and whitelists remain unchanged: You do not need to modify your application code after the change is complete.
Data is typically not lost: However, in the rare event that the original primary node fails during the switchover, a small amount of unsynchronized data may be lost.
One to two transient disconnections that last less than 30 seconds each: The instance experiences one to two transient disconnections, each lasting less than 30 seconds. Ensure that your application has a reconnection mechanism.
Read-only state for about one minute: The instance enters a read-only state for about one minute. This allows the new instance to synchronize with incremental data from the original instance and prevents data dual-write issues caused by DNS cache. For instances with high write workloads, the read-only period may be longer.
Lua scripts may be lost: The cluster architecture has certain limits on the use of Lua scripts. Lua scripts that do not meet these conditions may be lost when you change the instance architecture. Back up your scripts before you proceed. For more information, see Special limits on cluster instances.
More command limitations apply: The cluster architecture does not support some commands. Before you change the instance architecture, evaluate the impact of these command limitations on your business. For more information, see Command limitations for cluster instances.
The instance is upgraded to the latest minor version: To ensure optimal performance and stability, the system upgrades the instance to the latest minor version during the change if it is running an earlier version. Minor versions are forward-compatible, so this upgrade will not cause compatibility issues.

Limitations

If read/write splitting is enabled, you must first disable it.
Child instances of a distributed instance do not support architecture changes.
Tair (Enterprise Edition) SSD-based instances do not support architecture changes.

Procedure

Log on to the 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.
For a subscription instance, click Specification Adjustment > Specification Upgrade in the upper-right corner. For a pay-as-you-go instance, click Specification Adjustment > Specifications Upgrade/Downgrade in the upper-right corner.
On the specification change page, select the required configurations, and then click Buy Now.
Pay attention to the Switching Time parameter:
- Switch after Data Migration: The system switches to the new node immediately after data migration is complete.
- Switch Within Maintenance Window (Recommended): The system switches to the new node during the maintenance window (off-peak hours). Before the instance switchover, you can go to the Task Hub in the console and click Modify Switchover Time next to the corresponding task to change the switchover time.
Complete the payment process as prompted.
After you submit the request, the instance status immediately changes to Adjusting configuration, regardless of the Switching Time you selected. This does not affect the services provided by the instance. The system first prepares for the change, such as requesting resources and synchronizing data. Transient disconnections occur only when the system switches over to the new node.

Notes after the change:

The connection mode is proxy mode by default. You can view the number of client connections on the monitoring page of the proxy node. The number of connections to data nodes is displayed as 0.
Alert settings will be disabled, and the existing application groups in Cloud Monitor may also be disabled. To continue using these features, you must reconfigure them.
The data flashback feature will be disabled. To continue using this feature, you must reconfigure it.

Change from cluster to standard (master-replica)

Impacts

The endpoints, accounts, passwords, and whitelists remain unchanged: You do not need to modify your application code after the change is complete.
Data is typically not lost: However, in the rare event that the original primary node fails during the switchover, a small amount of unsynchronized data may be lost.
One to two transient disconnections that last less than 30 seconds each: The instance experiences one to two transient disconnections, each lasting less than 30 seconds.
Read-only state for about one minute: The instance enters a read-only state for about one minute. This allows the new instance to synchronize with incremental data from the original instance and prevents data dual-write issues caused by DNS cache. For instances with high write workloads, the read-only period may be longer.
The instance is upgraded to the latest minor version: To ensure optimal performance and stability, the system upgrades the instance to the latest minor version during the change if it is running an earlier version. Minor versions are forward-compatible, so this upgrade will not cause compatibility issues.

Limitations

If read/write splitting is enabled, you must first disable it.
Cluster instances in direct connection mode do not support architecture changes.
Tair (Enterprise Edition) SSD-based instances do not support architecture changes.

Procedure

Log on to the 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.
For a subscription instance, click Specification Adjustment > Specification Downgrade in the upper-right corner. For a pay-as-you-go instance, click Specification Adjustment > Specifications Upgrade/Downgrade in the upper-right corner.
On the specification change page, select the required configurations, and then click Buy Now.
Pay attention to the Switching Time parameter:
- Switch after Data Migration: The system switches to the new node immediately after data migration is complete.
- Switch During Maintenance Window (Recommended): The switchover to the new node is performed during the maintenance window (off-peak hours). Before the instance switchover, you can change the switchover time in the Task Hub of the console by clicking Modify Switchover Time next to the corresponding task.
Complete the payment process as prompted.
After you submit the request, the instance status immediately changes to Adjusting configuration, regardless of the Switching Time you selected. This does not affect the services provided by the instance. The system first prepares for the change, such as requesting resources and synchronizing data. Transient disconnections occur only when the system switches over to the new node.

Notes after the change:

Alert settings will be disabled, and the existing application groups in Cloud Monitor may also be disabled. To continue using these features, you must reconfigure them.
The data flashback feature will be disabled. To continue using this feature, you must reconfigure it.

FAQ

How long does a specification change take?

The duration of a specification change depends on multiple factors, such as network conditions, request volume, and data size. Therefore, the exact time required cannot be predicted.

You can monitor the task progress by clicking the icon in the upper-right corner of the instance details page.

When I change a standard instance to a cluster instance, is the data automatically migrated to each shard?

Yes. The system automatically migrates the data and ensures that it is evenly distributed across all shards.

Does the number of databases (DBs) change after the architecture is changed?

No. The default number of 256 DBs does not change.

How do I change the storage medium for a Tair (Enterprise Edition) instance?

Tair (Enterprise Edition) does not support changing the storage medium between different types, such as memory-optimized, persistent memory, and ESSD.

Can I upgrade only the CPU performance of an instance?

Tair (and Redis Open-Source Edition) does not support upgrading the CPU independently. You can use the following methods to improve the overall CPU performance of an instance:

Change the instance architecture from standard to cluster or read/write splitting.
Increase the number of read-only nodes for an instance that uses the read/write splitting architecture.
Increase the number of shards for a cluster instance.

For more information, see How to upgrade the CPU specifications of an instance.

For more information about instance types, see Instance types and FAQ.

Can a classic instance be directly upgraded to a cloud-native instance?

Yes. For more information, see Convert to the cloud-native deployment mode.

How do I change a high-availability (dual-replica) instance to a single-replica instance?

You cannot change a high-availability instance to a single-replica instance because single-replica instances do not guarantee data reliability.

If needed, you can purchase a separate high-availability instance and then use DTS to migrate its data to a single-replica instance. For more information, see Migration between Tair (Redis OSS-compatible) instances.

Do I need to pause read and write operations during a specification change?

No. However, because the instance may enter a read-only state for about one minute and experience one to two transient disconnections that last less than 30 seconds each, we recommend that you change the configuration and perform the switchover during off-peak hours.

Will a specification change cause backup sets to be lost?

Specification changes do not cause backup sets to be lost. However, when you reduce the number of shards for a classic cluster instance or change its architecture to standard, the mapping between historical backup sets and instance nodes changes.

To find historical backup sets in this scenario, search for them by backup time or backup set ID.

To complete the recovery, you can download the historical backup set (RDB file), parse it, and import the data into the new instance.

What do I do if the error "The direct custins can not trans to normal custins" occurs during a specification change?

This error occurs when you try to change the architecture of a classic cluster instance with a direct connection endpoint to the standard or read/write splitting architecture. This operation is not supported. To change the architecture, you must first release the direct connection endpoint.

After the specification change, why are the configurations not updated?

This may be caused by a delay in refreshing the metadata cache. Wait a few minutes and then refresh the page.