ApsaraDB RDS for MySQL provides remote 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 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 RDS instance has an internal endpoint.
  • The RDS instance resides in one of the following regions:
    • China (Hangzhou)
    • China (Shanghai)
    • China (Qingdao)
    • China (Beijing)
    • China (Shenzhen)
    • China (Hong Kong)
    • Singapore
    • US (Virginia)

Background information

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

You can use the Data Transmission Service 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 on an hourly basis.
  • Support whitelist configuration and account management.

Billing

Primary and 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 RDS instance and DTS. For more information, see Pricing for ApsaraDB RDS for MySQL and Pricing for Data Transmission Service.

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. Log on to the ApsaraDB for RDS console.
  2. In the top navigation bar, select the region where the target RDS instance resides.Select a region
  3. Find the target RDS instance and click its ID.
  4. In the Distributed by Instance Role section, click Add Guard.
  5. 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 RDS instance runs MySQL 5.6, you do not need to specify Database Account and Database Password. Skip this step.
  6. Click Buy Instance.
  7. In the Purchase Secondary Instance for Disaster Recovery dialog box, select the region and click Purchase.
    Note
    • If you purchase a disaster recovery instance, you can only select the region but cannot configure other parameters. The billing method is fixed at 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.
    • Creation of the disaster recovery instance takes several minutes. Do not close the dialog box during this period. Otherwise, the creation may fail.
  8. Click Create account to create a privileged account for synchronization. After the disaster recovery instance is purchased, its instance ID is automatically displayed at Instance ID in the Destination Instance Details section.
    Note If the RDS instance runs MySQL 5.6, the system automatically creates a synchronization account for DTS. Skip this step.
    Create account
  9. 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 RDS instance runs MySQL 5.6, click Set Whitelist and Next. Wait until the account is created. Then, click Next.
  10. 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
  11. Set Initial Synchronization and click Precheck.
    Note Initial Synchronization instructs the system to synchronize 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 either Initial Schema Synchronization or Initial Full Data Synchronization. If you perform data synchronization for the first time, you must select both of them.
  12. 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.

  13. On the Synchronization Tasks page, find the created synchronization task and click Start Task.
  14. After the precheck succeeds, click Close. The synchronization task starts.
  15. 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

  • Can I choose the subscription billing method for disaster recovery instances?

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

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

    If you create a disaster recovery instance for an 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.