All Products
Search
Document Center

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

Last Updated:Mar 28, 2025

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 the following types of 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

  • When you migrate an instance across zones, transient connections may occur. We recommend that you perform this operation during off-peak hours and make sure that your application can automatically reconnect to your instance.

  • Note

    ✅ 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 remains read-only for up to 1 minute during the migration. This ensures data consistency between the new instance and the original instance. 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 the migration during off-peak hours.

  • 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 an instance is deployed in a virtual private cloud (VPC), you cannot change the VPC when you migrate the instance across zones.

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

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

  2. In the Basic Information section, click Cross-zone Migration to the right of Zone.

  3. 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 a vSwitch.

    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.

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