ApsaraDB RDS for MySQL provides geo-disaster recovery instances to improve data reliability. This feature is suited for common scenarios that require high data reliability and financial businesses that need to meet regulatory requirements.

Prerequisites

  • The primary ApsaraDB RDS instance runs one of the following MySQL versions and RDS editions:
    • MySQL 8.0 on RDS High-availability or Enterprise Edition
    • MySQL 5.7 on RDS High-availability or Enterprise Edition
    • MySQL 5.6
  • The ApsaraDB RDS instance has an internal endpoint.
  • The primary instance is deployed in the China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Shenzhen), China (Hong Kong), Singapore (Singapore), or US (Virginia) region.

Background information

A primary instance and its geo-disaster recovery instance synchronize data with each other in real time by using Data Transmission Service (DTS). Both the primary and geo-disaster recovery instances are deployed based on the primary/secondary high-availability architecture. If your application cannot connect to the primary or secondary instance due to natural disasters, update the endpoints for your application to switch over services to the geo-disaster recovery instance. This minimizes the downtime of your database system.

You can use the DTS console to implement native features such as synchronization object changes, synchronization speed settings, and latency alerts for the disaster recovery instance. For more information, see DTS documentation.

The following figure shows the topology of a disaster recovery instance.

Disaster recovery instances have the following characteristics:

  • Provide separate endpoints for databases. You can configure your application to automatically select an endpoint or manually update the endpoint.
  • Use the primary/secondary high-availability architecture.
  • Use pay-as-you-go billing.
  • Support whitelist configuration and account management.

Billing

Primary and geo-disaster recovery instances use the same specifications and configurations, and their synchronization is implemented by using DTS in real time. If you create a disaster recovery instance, you must pay for both the ApsaraDB RDS instance and DTS. For more information, go to the ApsaraDB RDS pricing and DTS pricing pages.

Limits

  • Disaster recovery instances do not support backup and restoration, data migration, database management, public endpoints, and endpoint modification.
  • If a database is deleted from the primary instance, this operation is not synchronized to the disaster recovery instance. You must connect to the disaster recovery instance and execute an SQL statement to manually delete the database.

Procedure

  1. Go to the Basic Information page of the read-only ApsaraDB RDS instance.
    1. Log on to the ApsaraDB for RDS console. In the left-side navigation pane, click Instances. In the top navigation bar, select the region where your RDS instance resides.
      选择地域
    2. Find your ApsaraDB RDS instance and click its ID.
  2. In the Distributed by Instance Role section of the Basic Information page, click Add to the right of DR Instance. If you use the original ApsaraDB RDS console, click Add Guard in the Distributed by Instance Role section of the Basic Information page.
    Note If the preceding entries are not displayed, check whether your instance meets the prerequisites in this topic.
  3. In the Create Data Synchronization Task wizard, specify Database Account and Database Password.
    Note
    • Make sure that the account has REPLICATION SLAVE permissions, REPLICATION CLIENT permissions, and permissions to execute the SELECT statements on the required objects.
    • If the ApsaraDB RDS instance runs MySQL 5.6, you do not need to specify Database Account and Database Password. Skip this step.
  4. Click Buy Instance.
  5. In the Purchase Secondary Instance for Disaster Recovery dialog box, select a region and click Purchase.
    Note
    • If you purchase a disaster recovery instance, you can select only the region and cannot configure other parameters. The billing method can be set only to pay-as-you-go. Other settings are the same as those of the primary instance. If you want to upgrade the disaster recovery instance, change the specifications of the instance in the console after it is created.
    • The disaster recovery instance is created after several minutes. Do not close the dialog box during this period. Otherwise, the creation may fail.
  6. Click Create account to create a privileged account for synchronization. After the disaster recovery instance is purchased, its instance ID is displayed at Instance ID in the Destination Instance Details section.
    Note If the ApsaraDB RDS instance runs MySQL 5.6, the system automatically creates a synchronization account for DTS. Skip this step.
    Create account
  7. In the Create Data Synchronization Task wizard, specify Database Account and Database Password in the Destination Instance Details section. Click Set Whitelist and Next.
    Note If the ApsaraDB 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 to be synchronized and click > to move the objects to the Selected section. Click Next.
    Note If you want to change multiple table names at a time, select tables and select Change Database and Table Names. Click Advanced Settings. Change multiple table names at a time
    Select objects
  9. Set Initial Synchronization and click Precheck.
    Note During Initial Synchronization, the system synchronizes the schemas and data of the objects to be synchronized from the primary instance to the disaster recovery instance. The schemas and data are the basis for subsequent incremental data synchronization. You can select Initial Schema Synchronization or Initial Full Data Synchronization. If you perform data synchronization for the first time, you must select both of them.
    Initialize synchronization
  10. Perform the following operation if the precheck fails. Otherwise, go to Step 14.

    Click the icon next to Failed to view details and perform troubleshooting.

    Failed
  11. On the Synchronization Tasks page, find the created synchronization task and click Start Task.
    Perform another synchronization
  12. After the precheck succeeds, click Close. The synchronization task starts.
    Successful pre-check
  13. On the Synchronization Tasks page, query the created synchronization task and perform specific operations on the task. These operations include changing objects to be synchronized, setting monitoring alerts, and changing the synchronization speed. For more information, see DTS documentation.
    Note To ensure that data on the disaster recovery instance is up-to-date, do not pause the synchronization task.

FAQ

  • Q: When do I use a disaster recovery instance?

    A: When both the primary and secondary ApsaraDB RDS instances are unavailable due to natural disasters, you can switch the geo-disaster recovery ApsaraDB RDS instance to the primary role and update the endpoint configuration on your application. This minimizes the downtime of your database system.

    Switchover between primary and secondary instances
  • Q: Can I choose the subscription billing method for disaster recovery instances?

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

  • Q: I have not created the dtssyncwriter account but it appears. Why?

    A: If you create a disaster recovery instance for an ApsaraDB RDS instance that runs MySQL 5.6, the system automatically creates the dtssyncwriter account for DTS to synchronize data. Do not modify or delete this account. Otherwise, synchronization errors occur.