Migrate an instance across zones - Tair (Redis® OSS-Compatible)

If the current zone in which your instance is deployed has insufficient resources for a specification upgrade or if you want to improve the disaster recovery capability, you can migrate the instance to another zone by using the Tair (Redis OSS-compatible) console or calling an API operation. After the instance is migrated to another zone, the data, accounts, and endpoints of the instance remain unchanged.

Prerequisites

The instance has any additionally requested public endpoints and private endpoints released.

Note

If the instance has the preceding endpoints, release the endpoints before you migrate the instance. Otherwise, the Cross-zone Migration button is dimmed and the operation cannot be performed.

Precautions

Cloud-native instances

In certain scenarios, migrating instances across zones does not cause transient connections. However, in other cases, the migration may still cause transient connections. Therefore, we recommend that you perform this operation during off-peak hours and make sure that your application can automatically reconnect to your instance.
✅ No transient connections occur in the following scenarios:
- You add a secondary zone for a single-zone instance while keeping the primary zone unchanged.
- You change the secondary zone of a dual-zone instance. The master node is not deployed in the secondary zone.
⚠️ Transient connections occur in the following scenarios:
- You change the zone in which the master node resides. This includes the scenario in which a high-availability (HA) failover causes the master node to move to the secondary zone, which also results in a change to the secondary zone.
- You change the secondary zone of a read/write splitting instance when you use the endpoint of the secondary zone.
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 may remain read-only for up to 1 minute during the migration. If a large amount of data is written to the instance, the instance may remain read-only for an extended period of time.
Note
If the master node is not involved in the migration, the instance will not enter a read-only state.
When you migrate an instance across zones, the DNS mapping of the instance may change. In this case, make sure that you use the endpoints of the instance such as r-bp10b3fa3500****.redis.rds.aliyuncs.com to connect to the instance. In addition, earlier Jedis versions may not be able to obtain valid endpoints of the instance. You must update your Jedis client.
If the minor version of an instance is outdated, the system updates the instance to the latest minor version during migration to ensure better performance and stability. Minor versions are designed to be forward compatible, which eliminates compatibility issues.
After the migration, the bandwidth is reset to the default value. If the bandwidth was manually adjusted, it needs to be manually reset after the migration. Auto scaling automatically resumes the next time the rule is triggered.
Note
If the master node is not involved in the migration, the bandwidth plan remains intact and is not reset.

Classic instances

Migrating instances across zones may cause transient connections. 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 may remain read-only for up to 1 minute during the migration.
If a large amount of data is written to the instance, the instance may remain read-only for an extended period of time. Therefore, we recommend that you perform this operation during off-peak hours and make sure that your application can automatically reconnect to your instance.
When you migrate an instance across zones, the DNS mapping of the instance may change. In this case, make sure that you use the endpoints of the instance such as r-bp10b3fa3500****.redis.rds.aliyuncs.com to connect to the instance. In addition, earlier Jedis versions may not be able to obtain valid endpoints of the instance. You must update your Jedis client.
If the minor version of an instance is outdated, the system updates the instance to the latest minor version during migration to ensure better performance and stability. Minor versions are designed to be forward compatible, which eliminates compatibility issues.
After the migration, the bandwidth is reset to the default value. If the bandwidth was manually adjusted, it needs to be manually reset after the migration. Auto scaling automatically resumes the next time the rule is triggered.

Supported migration types and scenarios

Type	Scenario
Migrate an instance from one zone to another	You want to migrate the instance to the zone of a specific Elastic Compute Service (ECS) instance. An ECS instance and a Tair instance that are deployed in the same zone can communicate over an internal network at low network latency.
Migrate an instance from a set of zones to another
Migrate an instance from one zone to multiple zones	You want to implement disaster recovery across data centers for the instance. Single-zone instances can withstand server- and rack-level failures. Multi-zone instances can withstand data center-level failures and enhance disaster recovery capabilities by deploying resources across different data centers.
Migrate an instance from multiple zones to one zone	You want to migrate the instance based on specific business requirements.

Procedure

Warning

This operation may cause transient connections. We recommend that you perform this operation during off-peak hours and make sure that your application can automatically reconnect to your instance.

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 Basic Information section, click Cross-zone Migration to the right of Zone.

In the panel that appears, configure the parameters. The following table describes the parameters.

Parameter	Description
Destination Primary Zone	The primary destination zone to which you want to migrate the instance.
Destination Secondary Zone (optional)	The secondary destination zone to which you want to migrate the instance. If you configure this parameter, replica nodes of the instance are migrated to this zone. This ensures cross-zone disaster recovery. Note If you do not configure this parameter, the master and replica nodes of the instance are all migrated to the primary zone.
vSwitch	The destination vSwitch. If no vSwitch exists in the destination zone, you must create a vSwitch. For more information, see Create and manage vSwitches. Note This parameter is available and required only when the instance is deployed in a VPC.
Exec Time	Upgrade Now: After you click OK, the migration immediately starts. When the instance status changes to Running, the instance is migrated. Update During Maintenance (recommended): After you click OK, the pre-migration operations immediately start and the instance status changes to Migrating to Another Zone. During this process, the instance remains fully operational. The migration is not performed until the maintenance window starts. For more information, see Configure a maintenance window.
Nodes Per Shard in Primary Zone Nodes Per Shard in Secondary Zone	If the instance is a multi-replica cluster instance or read/write splitting instance that is deployed in cloud-native mode, you can use these parameters to modify the distribution of replica nodes or read replicas in the primary and secondary zones when you migrate the instance to multiple zones. When you perform the operation, you cannot change the total number of master and replica nodes. Note If the instance is a cluster instance, the preceding parameters indicate the number of replica nodes or read replicas per shard in the primary and secondary zones.

Read the prompt and select the check box. Then, click OK.

Related API operations

API operation	Description
MigrateToOtherZone	Migrates an instance across zones within the same region.

FAQ

Do the endpoints of an instance change when I migrate the instance across zones? Are existing data, whitelists, and database accounts lost?

When you migrate an instance across zones, the instance endpoints displayed in the console, such as r-bp10b3fa3500****.redis.rds.aliyuncs.com, do not change. However, the virtual IP address (VIP) and DNS mapping change. Take note of the following points:
- Make sure that you use an endpoint, such as r-bp10b3fa3500****.redis.rds.aliyuncs.com, to connect to the instance.
- If you use Jedis, make sure that the Jedis version is 3.10.0 or later. An earlier Jedis version may not be able to obtain valid endpoints. For more information, see Notice on Jedis update.
The migration does not cause data loss. You do not need to reconfigure the whitelists or database accounts.

Am I charged when I migrate an instance from one zone to multiple zones?

You are not charged when you migrate an instance from one zone to multiple zones.

Why am I unable to migrate my instance to a secondary zone?

If your instance is a standalone instance, no replica node or secondary zone is available for the instance. In this case, you cannot migrate the instance to a secondary zone.

If an instance is deployed in two zones, does the instance remain available when one zone fails?

Instances that are deployed in two or more zones can provide cross-zone disaster recovery. If one zone fails, the instances in the other zones can continue to provide services.

How do I view the migration progress?

You can view the migration progress in the Task Center.