All Products
Search
Document Center

ApsaraDB RDS:Use the data tracking feature of DMS to restore MySQL data

Last Updated:Mar 21, 2025

When making changes to a database, incorrect updates, deletions, or insertions can lead to data abnormalities. In such cases, you can utilize the data tracking feature of DMS to identify the change records within the desired time frame, provided the Binlog is available. This feature allows you to generate rollback scripts and swiftly revert the data to its pre-alteration state. DMS data tracking offers a more efficient and convenient solution compared to restoring full data or restoring database tables, greatly enhancing the efficiency of data restoration during routine operations and maintenance.

Note

For additional data restoration solutions, see the Overview of Data Restoration Solutions.

Differences between the data tracking feature and other restoration methods

Restoration Method

Restoration Principle

Cost

Restoration Speed

Restoration Scope

Data Tracking

Track the relevant updates within the target time period as needed, summarize and generate reverse rollback statements, and execute them in the database through a data change ticket to complete the data restoration.

  • If the control mode is Flexible Management, no fees are generated.

  • If the control mode is Stable Change or Security Collaboration, fees are charged.

Fast

Depends on the control mode and the Binlog retention period.

  • If the control mode is Flexible Management, only DML operations performed within 30 minutes can be tracked, and rollback or reconstruction scripts cannot be exported.

  • If the control mode is Stable Change or Security Collaboration:

Restoring Database Tables

Supports regular and rapid levels of database table restoration speed. You can restore specified database tables to a new instance or an existing instance. Restoring to an existing instance will trigger a primary-secondary switch.

  • If you restore to a new instance, you are charged for the new instance. For more information about the price, visit the ApsaraDB RDS buy page.

  • Fees are charged beyond the free quota for backup fees.

Rapid: Fast

Regular: Slow

Depends on the time point when database table backup is enabled and the log backup retention period, up to 730 days.

Restoring Full Data

Restore all data of the original RDS instance to a new RDS instance, verify the data on the new RDS instance, and then migrate the data from the new RDS instance back to the original RDS instance, an existing RDS instance, or an on-premises database instance.

  • You are charged for the new RDS instance. For more information about the price, visit the ApsaraDB RDS buy page.

  • Fees are charged beyond the free quota for backup fees.

  • Data transferred out through the public network is charged for traffic fees.

Slow

Depends on the log backup and data backup retention period, up to 730 days.

Prerequisites

  • A database of MySQL 5.6 or later is used.

  • The binary logging feature is enabled for the database.

  • You have logged on to the database in DMS.

    Note

    If the database instance to which the database belongs is managed in Flexible Management or Stable Change mode, you must log on to the database. If the database instance to which the database belongs is managed in Security Collaboration mode, you do not need to log on to the database.

Usage notes

  • For a database instance managed in Flexible Management mode, you can track DML operations that are performed within the previous 30 minutes but you cannot export rollback or rebuild scripts.

  • For a database instance managed in Stable Change or Security Collaboration mode, you can track data operations that are performed within the retention period of binary logs and export rollback or rebuild scripts.

  • The data operations that you can track are limited by the retention period of binary logs in a database. If data operations are performed beyond the retention period of binary logs, DMS cannot retrieve data for such operations.

  • If the binary logging feature is disabled for a database or you have not logged on to the database, DMS cannot obtain the binary logs of the database.

  • The data tracking feature allows you to track only DML operations. You cannot track DDL operations by using this feature.

Procedure

  1. Log on to the DMS console V5.0.
    1. In the top navigation bar, click Database Development > Data Tracking > Data Tracking Ticket.

    Note

    If you use the DMS console in simple mode, move the pointer over the 2023-01-28_15-57-17.png icon in the upper-left corner of the console and choose All Features > Database Development > Data Tracking > Data Tracking Ticket.

  2. In the upper-right corner of the Data Tracking Ticket page, click Data Tracking.

  3. On the Data Tracking Tickets page, configure the parameters that are described in the following table.

    Parameter

    Description

    Task Name

    Enter a name that facilitates future searches and helps approvers understand the purpose of the ticket.

    Database Name

    Select a database in a specific database instance. You must have the permissions to manage the database in DMS. You can enter the prefix of a database name in the field and select the database from the matched results.

    Table Name

    Select one or more tables for which you want to track data operations.

    Track Type

    Select one or more types of operations that you want to track.

    • Insert: INSERT statements are generated to roll back INSERT operations.

    • Update: UPDATE statements are generated to roll back UPDATE operations.

    • Delete: DELETE statements are generated to roll back DELETE operations.

    Time Range

    Specify a time range in which you want to track data operations.

    • If the database instance to which the database belongs is managed in Flexible Management mode, you can track only data operations that are performed within the previous 30 minutes.

    • If the database instance to which the database belongs is managed in Stable Change or Security Collaboration mode, you can track data operations that are performed within the retention period of binary logs. However, the time range is limited to a maximum of 48 hours in a single ticket. If you want to track data operations in a time range that exceeds 48 hours, split the time range and submit multiple tickets.

    Change Stakeholder

    Select the stakeholders involved in the ticket. Only the selected stakeholders and ticket approvers can view ticket details.

  4. Click Submit. DMS automatically obtains the binary logs of the database.

    After the binary logs are obtained, the ticket enters the Approval step.

  5. Wait until the ticket is approved.

    Note

    By default, a data tracking ticket for a database is approved by the database administrator (DBA) of the database. For more information about the approval rules for data tracking tickets, see Data tracking.

  6. After the ticket is approved, wait for DMS to download and parse the binary logs.

  7. After the binary logs are downloaded and parsed, you can specify filter conditions such as Track Type, Table Name, and Column Name to filter data changes that you want to roll back. Select data records and click Export Rollback Script. A rollback script is downloaded to your computer.

    Note
    • You can find a data record and click View Details to view the details of the data record and copy rollback statements.

    • You can track the following types of operations: INSERT, UPDATE, and DELETE.

Next step: rollback SQL

After exporting the rollback script, you can first roughly assess the impact of the rollback SQL on the data rows, and then choose how to execute the rollback SQL:

  • If the impact is minimal, you can run the SQL in the SQL window.

  • If the impact is significant, you can submit a standard data change ticket and include the rollback script as an attachment for execution in the target database. For more information, see Normal Data Change.

Related API

Use the API for data tracking: