The Cloud-native deployment mode is compatible with higher Redis versions and provides a more flexible architecture. This topic describes how to convert a Classic instance to a Cloud-native instance.
How it works
Ensure your application has a reconnection mechanism.
The instance becomes read-only for less than one minute during the conversion. This helps the new instance quickly synchronize incremental data and prevents dual-write issues caused by DNS caching. If the instance handles a large number of write requests, the read-only duration may be longer. We recommend that you perform the conversion during off-peak hours.
After the conversion, historical monitoring data and backups become invisible. If you need to retain historical backups, use the Backup Download feature to save them to your local system before the conversion.
Limitations
Billing requirements
Only pay-as-you-go instances are supported. Subscription instances must first be converted to pay-as-you-go instances.
Network configuration
Bandwidth adjustment
If you manually adjusted the bandwidth, you must restore it to the default setting.
If you enabled Auto Scaling for bandwidth, you must disable it.
Endpoints: You must release any public or direct connection endpoints on the cluster instance.
Security configuration
Add the IP addresses of all clients to the instance's whitelist. This includes clients in the instance's VPC and clients in other VPCs connected via tunnels. If you do not enable public access for the instance, you can add 0.0.0.0/0 to the whitelist. Then, set the parameter
#no_loose_check-whitelist-alwaystoyes.If a security group is configured for the instance, you must add the CIDR block of the VPC to the whitelist, remove the security group, and then convert the instance. After the conversion is complete, you can re-associate the security group with the instance.
Feature compatibility
Conversion is not supported if multi-zone read/write splitting or Global Distributed Cache is enabled.
If TLS connections or data flashback (PITR) is enabled, you must first disable these features.
Instances with TDE enabled can be converted only to a cloud-native instance that is compatible with Redis 6.0 or 7.0, not Redis 5.0.
Node type
Only dual-replica (high-availability) instances are supported. You must first upgrade single-replica (single-node) instances to dual-replica.
Considerations
After the conversion, no data is lost, and the instance ID, endpoint, accounts, passwords, and IP whitelist configurations remain unchanged.
If the original instance runs Redis 2.8 or 4.0, upgrade it to Redis 5.0 before converting.
After a Tair (Enterprise Edition) instance is converted to the cloud-native deployment mode, its Terraform resource type changes from
alicloud_kvstore_instancetoalicloud_redis_tair_instance. For more information, see Tair Resources.Switching to cloud-native deployment is irreversible. You cannot roll back to the classic deployment mode after the switch. Before you proceed, make sure you fully understand the impact. For more information, see Comparison between cloud-native and classic instances.
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.
In the Configuration section, click Convert to cloud-native.
Select the shard specifications and the number of shards for the converted instance.
Choose specifications equal to or higher than those of the original instance.
Select the Billing Method, compatible instance version, Switching Time, and other configuration items.
During this operation, you can also upgrade the instance to a version higher than Redis 5.0, such as Redis 6.0 or Redis 7.0. For more information, see New features and compatibility of major versions.
Read and select the checkbox to agree to the service agreement and the Conversion Notes. Then, click Buy Now.
The instance status changes to Changing Architecture Type. When the instance status changes to Running, the conversion is complete.
FAQ
Q: Why do I receive the "The capacity of the requested instance is insufficient" error message?
A: This error message indicates that Cloud-native resources are insufficient in the zone where your original instance is located. This issue may occur for instances that were created a long time ago. You can migrate the instance to another zone and try again.
Q: After the conversion is complete, I fail to connect to the instance by using DMS.
A: You must add the IP address of the DMS server to the whitelist.
Q: How do I upgrade from Redis 5.0 classic architecture to 7.0 cloud-native cluster architecture?
A: Complete the upgrade in stages (the instance ID, connection endpoint, credentials, and whitelist remain unchanged throughout. Perform the operations during off-peak hours):
Step 1: Convert to cloud-native deployment mode and upgrade to Redis 7.0. Converting to cloud-native mode supports only pay-as-you-go instances, so first check the instance's billing method:
If the instance is already pay-as-you-go: perform "Convert to cloud-native deployment mode" (the operation described in this topic) directly, and select to upgrade the instance to Redis 7.0 during the operation.
If the instance is subscription: convert it to pay-as-you-go first, then convert to cloud-native mode and upgrade to 7.0. You can switch back to subscription after the change is complete.
In addition, converting to cloud-native mode requires a dual-replica (high-availability) instance; a single-replica instance must be scaled up to dual-replica first. Impact: one connection interruption of less than 30 seconds, and about 1 minute of read-only state.
Step 2: Change to cluster architecture (proxy mode). See Change instance architecture. Impact: one to two connection interruptions of less than 30 seconds each, and about 1 minute of read-only state.
If you did not upgrade to 7.0 directly in step 1, you can upgrade the major version separately. See Upgrade the major version.