Docs

RDS for MySQL

Managing disaster instances

Create disaster recovery instance

RDS for MySQL supports creating cross-regional disaster recovery instances to provide disaster recovery capabilities across regions. This topic describes the steps to create a disaster recovery instance.

Background

A disaster recovery instance is a failover instance for the primary instance. The disaster recovery instance can only accept data synchronized from the primary instance through the Data Transmission Service and cannot receive data writes from other sources.

To ensure synchronization between the disaster recovery instance and the primary instance, the following configurations for the disaster recovery instance must be the same as the primary instance:

Database version

Engine type

Instance type

Storage type

Network protocol type

Rules for lower case table names

Parameter configuration (excluding memory and other resource-related parameters)

Affiliate project

Allowlists

Deletion protection

Prerequisites

To create a disaster recovery instance, ensure your account balance is greater than or equal to 100 CNY.

Limitation

A primary instance can have only one disaster recovery instance.

Disaster recovery instances do not support database operations or backup and recovery operations.

Disaster recovery instances can only receive data synchronized from the primary instance via Database Transmission Service (DTS), and cannot accept data writes from other sources.

Disaster recovery instances only support pay-as-you-go billing method.

Only Chinese mainland regions support creating same-region and cross-regional disaster recovery instances for an instance. The Hong Kong (China) region only supports creating same-region disaster recovery instances.

The storage space of a disaster recovery instance must be greater than or equal to the storage space of the primary instance and the minimum storage space of the instance specification.

It is recommended that the specification of the disaster recovery instance is not lower than that of the primary instance.

Enabling SSL for disaster recovery instances is not currently supported.

Creating a disaster recovery instance for a green instance in a blue-green deployment is not supported.

MySQL 8.4 instances do not support creating a disaster recovery instance.

Procedure

Log on to the RDS for MySQL console.

In the upper-left corner of the top menu bar, select the project and region for the instance.

tip

If the project of the instance has not been set, the project should be selected as All resources.

In the left navigation bar, click Instances to view the list of RDS for MySQL instances.

On the Instances page, click the name of the target instance to go to the Summary tab.

Click the Connectivity tab. In the Instance topology area, click Add disaster recovery instance to go to the Add disaster recovery instance page.

On the Add disaster recovery instance page, complete the settings and click Confirm order to go to the Confirm order page.

Parameter	Description
Instance name	Set the instance name (optional). The naming rules are as follows: It cannot start with a digit or hyphen (-). It can contain only Chinese characters, letters, digits, underscores (_), and hyphens (-). The length is 1~128 characters. tip If left blank, the instance ID will be used as the instance name by default.
Region	Select the region for the disaster recovery instance.
Storage type	Select the storage type for the instance. RDS for MySQL offers four storage types: Local SSD, High performance cloud disk, Cloud ESSD FlexPL, and Cloud ESSD PL0. The available storage types for the disaster recovery instance depend on the storage type of the primary instance, as follows: If the primary instance uses Local SSD, the disaster recovery instance can use Local SSD, Cloud ESSD FlexPL, Cloud ESSD PL0, or High performance cloud disk. If the primary instance uses Cloud ESSD FlexPL or Cloud ESSD PL0, the disaster recovery instance can use Cloud ESSD FlexPL, Cloud ESSD PL0, or High performance cloud disk, but not Local SSD.
Specification type	Support General type (formerly "shared type") and Dedicated type (formerly "general type") two specification types. General type: Exclusive use of allocated memory and storage resources, shares CPU resources with other shared instances in the same physical machine.CPU utilization is maximized through resource reuse, with high cost performance. CPU utilization is maximized through resource reuse, with high cost performance. Dedicated type: Fully exclusive use of allocated CPU, memory, and storage resources, with stable performance, not affected by other instances in the physical machine.
Node specification	Configure the number of nodes and node specifications for the instance. The configuration rules are as follows: If you choose the instance type as Double node: Up to 10 read-only nodes can be added, and the data on each node is exactly the same as the primary node. You can specify different availability zones in the same region for the primary node and the secondary node. tip For zone-level disaster recovery, it is recommended to deploy the primary and secondary nodes in different availability zones. The specification of the secondary node is consistent with that of the primary node. Up to 10 read-only nodes can be added, and the specifications of the read-only nodes can be set on demand. tip If the specification of a read-only node is lower than that of the primary node, high load on the primary node may cause latency or even OOM in the read-only node. It is recommended to select the same or a higher specification for the read-only nodes as that of the primary node. Primary, secondary, and read-only nodes can be deployed in up to three availability zones. If you choose the instance type as Multiple node: The specification of the secondary node is consistent with that of the primary node. You can add up to 8 secondary nodes, and at least 1 secondary node needs to be reserved. Nodes can be distributed in at most 3 availability zones. tip For zone-level disaster recovery, it is recommended to deploy the primary and secondary nodes in different availability zones. tip For multi-node instances, it is recommended to reserve an independent secondary node that does not carry business, so that it can be switched to the primary node if necessary. RDS for MySQL assumes no responsibility for any risks or losses incurred due to the failure to configure independent secondary nodes or the inability to complete the primary node switching due to excessive latency of all secondary nodes.
Storage space	Storage space includes data space, system file space, Binlog file space, and transaction file space. Enter a storage space in the range of 20 GiB to 32,000 GiB, with a step size of 10 GiB. Select a value based on your business needs. tip The storage space of a disaster recovery instance must be greater than or equal to the storage space of the primary instance and the minimum storage space of the instance specification. For more information on the value range of storage space corresponding to each specification, refer to Product specifications.
Virtual private cloud	Select the target VPC from the drop-down list. You can also click Create VPC on the right to create a new VPC. For more information on this operation, refer to Creating a VPC. tip A Virtual Private Cloud (VPC), is an isolated network environment with higher security and performance than those of the traditional classic network. You can only choose from the VPC resources under the project that can be accessed by the current account. Creating MySQL instances with shared VPCs is not supported, and shared VPCs are not displayed in the drop-down list.
Subnet	Choose an available subnet in the selected VPC. tip A subnet is an IP address block in the VPC. All cloud resources in the VPC must be deployed in subnets. For more information, refer to Creating a subnet. By default, the subnet uses Automatic IP assignment to assign private network IP addresses. You can click the assignment method drop-down list, select Manual IP assignment, and then specify a correct and unused IP address in the pop-up box. A MySQL instance can only use subnets in the availability zones of its primary or secondary nodes. Subnet and VPC can be classified into different projects. Confirm that the target subnet and the selected VPC belong to the same project, which can be checked in the Project console.
Proxy configuration	If the type of instance created is multi-node, you need to configure the proxy for the instance and set the number of cores for the instance proxy service. tip The proxy function of a multi-node instance cannot be disabled. The default is the number of recommended proxy cores. The recommended number of proxy cores is the total number of CPUs of all serviceable nodes of the instance * 0.25 (round up the result). For example, an instance has a primary node and a secondary node, and the number of CPUs for both the primary and secondary nodes is 8. Since (8+8)0.25=4, the number of recommended proxy cores is 4. The upper limit of the number of proxy cores is 1024, and the lower limit is the total number of CPUs of all serviceable nodes of the instance 0.125, and the result is rounded up. For example, an instance has a primary node and a secondary node, and the number of CPUs for both the primary and secondary nodes is 16. Since (16+16)*0.125=4, the minimum number of proxy cores is 4. RDS for MySQL provides 2 cores of free proxy resources for each instance, and the excess is charged according to the number of cores. For detailed billing information about dbatman services, please refer to Billing items and prices. Proxy configuration for a double-node instance during creation is not supported. You can enable the proxy feature after creating the instance. For more information, refer to Enabling the database proxy.
Kernel version upgrade policy	Method for upgrading the database kernel minor version. The following types are supported. Automatic: When a new kernel minor version is released, the instance is automatically upgrades to the latest kernel minor version during the configured Maintenance window. Manual: When a new kernel minor version is released, you must manually upgrade to the latest kernel version in the console. For details, refer to Manually upgrading the instance kernel version. tip If an instance's kernel minor version exceeds its maintenance cycle, the system temporarily ignores the upgrade policy and automatically upgrades the kernel minor version.

On the Confirm order page, confirm the order details, read and check the Database Products and Service Terms and Unsubscription Rules, and click Buy now.

tip

The Add disaster recovery instance page shows the creation progress of the disaster recovery instance.

After the disaster recovery instance is created, you can view the instance in the Instances list of its region. Click Task center to view details about the disaster recovery instance creation.

Billing for the disaster recovery instance starts upon its creation. Click Create synchronization link as soon as possible to establish a synchronization link between the primary and disaster recovery instances.

After the disaster recovery instance is created, the primary instance and the disaster recovery instance are marked with "Primary" and "Disaster recovery" respectively.

Subsequent steps

Create synchronization link

Related API

API	Description
DescribeDisasterRecoveryRegions	Call the DescribeDisasterRecoveryRegions API to view the list of regions where disaster recovery instances can be created.
CreateDrDBInstance	Call the CreateDrDBInstance API to create a disaster recovery instance for the specified instance.

Last updated: 2026.08.05 14:44:56