This topic describes how to create a disaster recovery RDS instance for a primary ApsaraDB RDS for MySQL instance in a different region than the primary RDS instance. If a primary RDS instance requires high data reliability or strict compliance with financial regulations, you can create a disaster recovery RDS instance for the primary RDS instance.

Prerequisites

  • The primary RDS instance runs one of the following MySQL versions and RDS editions:
    • MySQL 8.0 on RDS High-availability Edition or RDS Enterprise Edition
    • MySQL 5.7 on RDS High-availability Edition or RDS Enterprise Edition
    • MySQL 5.6
  • The primary RDS instance has an internal endpoint. For more information, see View and change the internal and public endpoints and port numbers of an ApsaraDB RDS for MySQL instance.
  • The primary RDS instance resides in China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Shenzhen), China (Hong Kong), Singapore (Singapore), or US (Virginia).

Background information

A primary RDS instance and its disaster recovery RDS instance synchronize data with each other in real time by using Data Transmission Service (DTS). The primary RDS instance and the disaster recovery RDS instance both run in a high-availability architecture. If the primary RDS instance and the secondary RDS instance cannot be connected due to unexpected exceptions such as natural disasters, the database system can fail over to the disaster recovery RDS instance. In this case, the disaster recovery RDS instance is promoted to run as the new primary RDS instance. After you update the endpoint configuration on your application, your application can immediately connect to the new primary RDS instance.

In the DTS console, you can change the synchronization objects, specify the synchronization speed, and configure alerts that are reported at a specified latency for a disaster recovery RDS instance. For more information, see What is DTS?

The following figure shows the topology of a database system in which a disaster recovery RDS instance is deployed.

Topology of a database system with a disaster recovery RDS instance

A disaster recovery RDS instance has the following characteristics:

  • A disaster recovery RDS instance can be connected over an independent endpoint. You can configure your application to automatically connect to the endpoint of the disaster recovery RDS instance.
  • A disaster recovery RDS instance runs in a high-availability architecture.
  • You are charged for a disaster recovery RDS instance based on the pay-as-you-go billing method.
  • You can configure IP address whitelists and manage accounts on a disaster recovery RDS instance.

Billing

A primary RDS instance and its disaster recovery RDS instance have the same configuration. These instances synchronize data with each other in real time by using DTS. Therefore, if you create a disaster recovery RDS instance, you are charged for both ApsaraDB RDS and DTS. For more information, visit the ApsaraDB RDS pricing page and the DTS pricing page.

Limits

  • A disaster recovery RDS instance does not support backups, restoration, data migration, database management, public endpoints, or endpoint modification.
  • A disaster recovery RDS instance does not synchronize operations such as database deletion from its primary RDS instance. After you delete a database from the primary RDS instance, you must log on to the disaster recovery RDS instance and execute SQL statements to delete the database.

Procedure

  1. Visit the RDS instance list, select a region above, and click the target instance ID.
  2. In the Distributed by Instance Role section of the Basic Information page, click Add to the right of DR Instance. If you are using the original ApsaraDB RDS console, click Add Guard in the Distributed by Instance Role section of the Basic Information page.
    Note If the preceding entry points cannot be found, you can check whether the primary RDS instance meets all requirements that are described in the "Prerequisites" section of this topic.
  3. In the Create Data Synchronization Task wizard, configure the Database Account and Database Password parameters.
    Note
    • The account must have the REPLICATION SLAVE, REPLICATION CLIENT, and SELECT permissions on all synchronization objects.
    • If the primary RDS instance runs MySQL 5.6, you can skip this step because you do not need to set the Database Account parameter or the Database Password parameter.
  4. Click Buy Instance.
  5. In the Purchase Secondary Instance for Disaster Recovery dialog box, select a region and click Purchase.
    Note
    • You can select only the region of the disaster recovery RDS instance. The disaster recovery RDS instance supports only the pay-as-you-go billing method. All the other settings of the disaster recovery RDS instance are the same as the settings of its primary RDS instance. After the disaster recovery RDS instance is created, you can change its specifications in the ApsaraDB RDS console.
    • ApsaraDB RDS requires a few minutes to create the disaster recovery RDS instance. Do not close the dialog box until the disaster recovery RDS instance is created. If you close the dialog box, the disaster recovery RDS instance may fail to be created.
  6. After the disaster recovery RDS instance is created, click Create account next to Instance ID in the Destination Instance Details section to create a privileged account that is used by DTS to synchronize data.
    Note If the primary RDS instance runs MySQL 5.6, you can skip this step because a privileged account is automatically created.
    Create account
  7. In the Create Data Synchronization Task wizard, configure the Database Account and Database Password parameters in the Destination Instance Details section. Then, click Set Whitelist and Next.
    Note If the primary RDS instance runs MySQL 5.6, click Set Whitelist and Next. Wait until the account is created. Then, click Next.
  8. In the Available section, select the objects that you want to synchronize and click the > icon to move the objects to the Selected section. Then, click Next.
    Note If you want to change the names of multiple tables at a time, select these tables and select Change Database and Table Names. Then, click Advanced Settings. Change multiple table names at a time
    Select objects
  9. Set the Initial Synchronization parameter and click Precheck.
    Note During the Initial Synchronization process, DTS synchronizes the schemas and data of the selected objects from the primary RDS instance to the disaster recovery RDS instance. The schemas and data are used by DTS as a basis to synchronize the incremental data of the primary RDS instance to the disaster recovery RDS instance. You can select the Initial Schema Synchronization option or the Initial Full Data Synchronization option. If you synchronize data for the first time, you must select both options.
    Initial Synchronization
  10. View the check items. This step is required only when the precheck fails. If the precheck is successful, go to Step 14.

    Find each failed check item and click the icon next to Failed to view the details about the failure. You can troubleshoot the issues that cause the failure.

    Failed
  11. On the Synchronization Tasks page, find the synchronization task that is created and click Start Task.
    Perform synchronization again
  12. After you verify that the precheck is successful, click Close. The synchronization task starts.
    Successful precheck
  13. On the Synchronization Tasks page, view and manage the synchronization task that is created. For example, you can change the synchronization objects, configure the monitoring and alerting feature, and change the synchronization speed. For more information, see What is DTS?
    Note To ensure that the data of the disaster recovery RDS instance is up-to-date, do not pause the synchronization task.

FAQ

  • What benefits does the disaster recovery RDS instance of a database system bring?
    If a primary RDS instance and its secondary RDS instance cannot be connected due to unexpected exceptions such as natural disasters, the database system can fail over to the disaster recovery RDS instance. In this case, the disaster recovery RDS instance is promoted to run as the new primary RDS instance of your database system. After you update the endpoint configuration on your application, your application can immediately connect to the new primary RDS instance.
    Note Data that is written to the new RDS instance cannot be synchronized to the original primary RDS instance.
  • Can I select the subscription billing method for disaster recovery RDS instances?

    No, disaster recovery RDS instances support only the pay-as-you-go billing method.

  • Why do I find an account named dtssyncwriter that I did not create?

    If a primary RDS instance runs MySQL 5.6, an account named dtssyncwriter is automatically created when you create a disaster recovery RDS instance. The dtssyncwriter account is used by DTS to synchronize data. Do not modify or delete this account. If you modify or delete this account, synchronization errors occur.