Change the zone of an instance - Tair (Redis® OSS-Compatible)

You can change the zone of a Tair (Redis OSS-compatible) instance using the console or an API operation if zone resources are insufficient for an instance type upgrade, you need to improve disaster recovery capabilities, or you need to move an instance for other reasons. After the zone is changed, the instance data, database accounts, endpoints, and other information remain unchanged.

Prerequisites

If a cloud-native instance has a public endpoint, you must release the public endpoint first.
If a classic instance has a public endpoint or a direct connection endpoint, you must release the public endpoint and release the direct connection endpoint first.

Considerations

Cloud-native instances

In some scenarios, a zone migration does not cause a transient disconnection. In other scenarios, a transient disconnection may occur. We recommend that you ensure your application has a reconnection mechanism and perform the migration during off-peak hours.
✅ No transient disconnection
- The instance is in a single zone, and you add a secondary zone. The primary zone remains unchanged.
- The instance is deployed across two zones, and you change only the secondary zone, which does not contain a primary node.
⚠️ Transient disconnection
- You change the zone that hosts the primary node. This includes cases where a high-availability (HA) switchover moves the primary node to the secondary zone, and you then change that secondary zone.
- You change the secondary zone of a read/write splitting instance while you are connected to the instance using the secondary zone endpoint.
The instance may enter a read-only state for up to 60 seconds. This allows the new instance to synchronize incremental data and prevents double writes that can be caused by the DNS cache. In high-write scenarios, this read-only period may be longer.
Note
No read-only state occurs if the primary node is not migrated.
A zone migration changes DNS mappings. Always connect to the instance using its endpoint, for example, r-bp10b3fa3500****.redis.rds.aliyuncs.com. Older Jedis versions may fail to resolve a valid endpoint after the migration. For more information, upgrade your Jedis client.
To ensure optimal performance and stability, the system automatically upgrades your instance to the latest minor version during a zone migration if the instance runs an outdated minor version. Minor versions maintain forward compatibility. Therefore, compatibility issues do not occur.
After the migration, the bandwidth is reset to the default value. If you previously adjusted the bandwidth manually, you must reconfigure it after the migration. Auto Scaling restores your custom bandwidth settings when the next scaling rule is triggered.
Note
If the primary node is not migrated, the bandwidth plan remains unchanged and is not reset.

Classic instances

A zone migration may cause a transient disconnection. The instance also enters a read-only state for up to 60 seconds. This allows the new instance to synchronize incremental data and prevents double writes that can be caused by the DNS cache.
In high-write scenarios, the read-only period may be longer. We recommend that you ensure your application has a reconnection mechanism and perform the migration during off-peak hours.
A zone migration changes DNS mappings. Always connect to the instance using its endpoint, for example, r-bp10b3fa3500****.redis.rds.aliyuncs.com. Older Jedis versions may fail to resolve a valid endpoint after the migration. For more information, upgrade your Jedis client.
To ensure optimal performance and stability, the system automatically upgrades your instance to the latest minor version during a zone migration if the instance runs an outdated minor version. Minor versions maintain forward compatibility. Therefore, compatibility issues do not occur.
After the migration, the bandwidth is reset to the default value. If you previously adjusted the bandwidth manually, you must reconfigure it after the migration. Auto Scaling restores your custom bandwidth settings when the next scaling rule is triggered.

Supported migration types and scenarios

Supported migration types	Common scenarios
Migrate from a single zone to a single zone	You can migrate the instance to the same zone as your ECS instance. ECS instances and databases in the same zone can connect over the internal network with lower latency.
Migrate from multi-zone to multi-zone
Migrate from a single zone to multi-zone	You can improve disaster recovery by enabling cross-data-center resilience. A single-zone instance is resilient to server-level and rack-level failures. A multi-zone instance is deployed across data centers and can withstand full data center outages. This significantly enhances disaster recovery.
Migrate from multi-zone to a single zone	Meets the requirements for specific features.

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 Migrate next to the Zone.

In the panel that appears, configure the parameters.

Setting	Description
Primary zone change	Select the target zone.
Secondary zone change (optional)	After specifying a secondary zone, the instance’s secondary node migrates to that zone, enabling cross-zone disaster recovery. Note If you do not specify a secondary zone, both primary and secondary nodes migrate to the primary zone.
Virtual Switch:	Select the destination vSwitch for migration. If no vSwitch exists in the target zone, create one first. For more information, see Create and manage vSwitches. Note This option appears and requires configuration only if the instance uses a virtual private cloud (VPC).
Executed At	Update Now: After clicking OK, the system starts the migration task immediately. The migration succeeds when the instance status becomes Running. Update During Maintenance (recommended): After clicking OK, the system performs preliminary migration tasks and changes the instance status to Migrating to Another Zone. The instance remains available during this phase. The actual switchover occurs only during the configured maintenance window. For more information, see Set a maintenance window.
Primary zone nodes per shard Secondary zone nodes per shard	If the instance is a cloud-native type (cluster multi-replica or read/write splitting), you can adjust how replica (or read-only) nodes distribute between primary and secondary zones during multi-zone migration. This setting does not change the total number of primary and secondary nodes. Note For cluster architecture instances, these parameters represent the number of replica (read-only) nodes per shard in the primary and secondary zones, respectively.

Read the warning message, select the check box, and then click OK.

Related API

API operation	Description
MigrateToOtherZone - Migrate an instance to another zone	Migrates an instance to another zone within the same region.

FAQ

Does the instance endpoint change after zone migration? Are existing data, whitelist settings, and database accounts lost?

After a zone migration, the instance endpoint, such as r-bp10b3fa3500****.redis.rds.aliyuncs.com, does not change. However, the virtual IP address (VIP) and DNS mapping change. Therefore, take note of the following points:
- Always use the endpoint, for example, r-bp10b3fa3500****.redis.rds.aliyuncs.com, to connect to the instance.
- If you use Jedis, ensure that its version is 3.10.0 or later. Older versions may fail to resolve a valid endpoint after the migration. For more information, see Jedis client upgrade recommendations.
A zone migration does not cause data loss and does not require you to reconfigure whitelists or database accounts.

Is there a charge for migrating an instance from a single zone to multi-zone?

No, migrating an instance from a single zone to multi-zone incurs no additional charges.

Why can’t I migrate my instance to a secondary zone?

A standalone instance does not have a secondary node. Therefore, a secondary zone does not exist, and you cannot perform this migration.

My instance is deployed across two zones. If one zone fails, is the instance still available?

Yes, it is. An instance that is deployed across two or more zones supports cross-zone disaster recovery. If one zone fails, the other node continues to process requests.

How do I check the progress of a zone migration?

You can view the migration progress in Task Hub in the console.