Change tracking monitors incremental data from your source database in real time, enabling use cases such as lightweight cache updates, asynchronous business decoupling, and real-time ETL (extract, transform, and load) pipelines.
This topic covers how to create a change tracking task for an ApsaraDB RDS for MySQL instance.
Prerequisites
Before you begin, ensure that you have:
-
An ApsaraDB RDS for MySQL instance. For supported database versions, see Overview of change tracking scenarios.
-
A VPC and a vSwitch for the change tracking instance to run in.
-
A database account on the source instance with the required permissions (see Database account requirements below).
-
Binary log settings configured correctly (see Binary log requirements below).
Database account requirements
The database account used to connect DTS to your source instance needs one of the following permission sets:
-
Read-only permissions on the instance, or
-
A custom account with all four of the following privileges: REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, and SELECT.
Replace <dts_user> with your actual database account name.
Binary log requirements
The following binlog settings must be in place before you start the change tracking task. Missing any of these causes the precheck to fail.
| Parameter | Required value | How to check |
|---|---|---|
| Binary logging | Enabled (on by default for ApsaraDB RDS for MySQL) | Binary logging is enabled by default. |
binlog_row_image |
full |
Run SHOW VARIABLES LIKE 'binlog_row_image'; — see View the parameters of an ApsaraDB RDS for MySQL instance |
| Binary log retention — ApsaraDB RDS for MySQL | At least 3 days (7 days recommended) | See Manage binary log files |
| Binary log retention — self-managed MySQL | At least 7 days | Set binlog_expire_log_days in my.cnf or my.ini |
If the binary log retention period is too short, DTS may fail to retrieve the logs, causing the task to fail. In exceptional cases, this can result in data loss. The DTS Service Level Agreement (SLA) does not guarantee service reliability or performance if the retention period requirements are not met.
Limitations
Review the following limitations before creating your task.
Source database
| Limitation | Details |
|---|---|
| Primary key or unique constraint | Source tables must have a PRIMARY KEY or UNIQUE constraint, with all fields unique. Without this, tracked data changes may contain duplicates. |
| Maximum tracked tables | Up to 500 tables per change tracking task. If you run a change tracking task to track more than 500 tables, a request error occurs. In this case, configure multiple tasks in batches or track the entire database instead. |
| FLOAT and DOUBLE precision | DTS uses ROUND(COLUMN,PRECISION) to retrieve values from these columns. Default precision: 38 digits for FLOAT, 308 digits for DOUBLE. Verify that the default precision meets your requirements before starting the task. |
| pt-online-schema-change DDL | DTS does not track DDL operations performed by pt-online-schema-change. This can cause schema conflicts when the change tracking client writes consumed data to the destination. |
| Row size limit | Rows larger than 16 MB cannot be consumed. Attempting to do so causes an out of memory (OOM) error on the change tracking client. |
| Read-only or temporary instances | The instance must record transaction logs. To check: log on to the RDS console (see View a read-only RDS instance) or run SHOW VARIABLES LIKE 'read_only'; — if the result is ON, the instance is read-only. |
Task recovery
If a DTS task fails, DTS support will attempt to restore it within 8 hours. During recovery, the task may be restarted and task parameters may be modified. Database parameters are not modified.
Create a change tracking task
Step 1: Go to the Change Tracking Tasks page
Use either the DTS console or the DMS console.
DTS console
-
Log on to the DTS console.
-
In the left-side navigation pane, click Change Tracking.
-
In the upper-left corner, select the region where your change tracking instance will reside.
DMS console
The exact navigation path may vary depending on your DMS console mode and layout. For details, see Simple mode and Customize the layout and style of the DMS console.
-
Log on to the DMS console.
-
In the top navigation bar, move the pointer over Data + AI > DTS (DTS) > Change Tracking.
-
To the right of Change Tracking Tasks, select the region where your change tracking instance will reside.
Step 2: Configure source database and consumer network
-
Click Create Task.
-
On the task configuration page, review the Limits displayed at the top before filling in any parameters.
-
Configure the following parameters:
General
| Parameter | Description |
|---|---|
| Task Name | DTS auto-assigns a name. Optionally, enter a descriptive name to make the task easier to identify. A unique name is not required. |
Source Database
| Parameter | Description |
|---|---|
| Select Existing Connection | Select an existing database connection to auto-fill the parameters below, or configure the connection manually. To register a new connection: in the DTS console, use the Database Connections page; in the DMS console, click Add DMS Database Instance. See Manage database connections. |
| Database Type | Select MySQL. |
| Access Method | Select Alibaba Cloud Instance. |
| Instance Region | The region where the source ApsaraDB RDS for MySQL instance resides. |
| Replicate Data Across Alibaba Cloud Accounts | Select No for same-account access. For cross-account access, select Yesalert notification settings and specify the Alibaba Cloud Account and RAM Role Name. Cross-account access also requires Resource Access Management (RAM) authorization — see Configure RAM authorization for cross-account DTS tasks. |
| RDS Instance ID | The ID of the ApsaraDB RDS for MySQL instance. |
| Database Account | The database account with the required permissions (see Database account requirements). |
| Database Password | The password for the database account. |
| Encryption | Select Non-encrypted or SSL-encrypted. If you choose SSL-encrypted, enable SSL encryption on the RDS instance first — see Configure SSL encryption. |
Consumer Network Type
| Parameter | Description |
|---|---|
| Network Type | Fixed to VPC. Select the VPC and vSwitch for the change tracking instance. If your change tracking client is deployed in a VPC, select the same VPC and vSwitch to minimize network latency. This setting cannot be changed after the task is configured. See VPCs. |
-
Click Test Connectivity and Proceed.
Ensure DTS server CIDR blocks are added to the security settings of your source database. See Add the CIDR blocks of DTS servers. If the source database is self-managed, click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.
Step 3: Select objects for change tracking
On the Configure Objects page, configure the following:
| Parameter | Description |
|---|---|
| Data Change Types | Fixed and cannot be modified. Data Update tracks INSERT, DELETE, and UPDATE operations on selected objects. Schema Update tracks create, delete, and modify operations on all object schemas in the source instance — use the change tracking client to filter the tracked data. |
| Source Objects | Select one or more objects and click  to add them to Selected Objects. Select databases to track all objects including new tables added later. Select tables to track only those tables — to add more tables later, see Modify the objects for change tracking. |
Step 4: Configure advanced settings
Click Next: Advanced Settings and configure the following parameters:
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | By default, the task runs on a shared cluster. To run on a dedicated cluster, purchase one first — see What is a DTS dedicated cluster. |
| Retry Time for Failed Connections | How long DTS retries after a connection failure. Valid values: 10–1440 minutes. Default: 720 minutes. Set this to at least 30 minutes. If DTS reconnects within this window, the task resumes; otherwise it fails. Note: when multiple tasks share the same database instance, the shortest retry time takes precedence. DTS continues charging during retries — set an appropriate window based on your requirements. |
| Retry Time for Other Issues | How long DTS retries after DDL or DML operation failures. Valid values: 1–1440 minutes. Default: 10 minutes. Set this to at least 10 minutes. This value must be less than Retry Time for Failed Connections. |
| Whether to delete SQL operations on heartbeat tables of forward and reverse tasks | Controls whether DTS writes heartbeat table SQL operations to the source database. Yes: does not write operations — change tracking latency may appear in monitoring. No: writes operations — may affect physical backup and cloning of the source database. |
| Environment Tag | An optional tag to identify the DTS instance's environment. |
| Monitoring and Alerting | Select Yes to receive alert notifications when the task fails or latency exceeds the threshold. When enabled, configure the alert threshold and notification settings. See Configure monitoring and alerting when you create a DTS task. |
Step 5: Save settings and run the precheck
Click Next: Save Task Settings and Precheck.
To preview the API parameters for this task configuration, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.
The task must pass the precheck before it can start.
-
If any item fails, click View Details next to the failed item, resolve the issue based on the error message, and run the precheck again.
-
If an item generates an alert:
-
If the alert cannot be ignored, click View Details, resolve the issue, and run the precheck again.
-
If the alert can be ignored, click Confirm Alert Details. In the dialog box, click Ignore > OK, then click Precheck Again.
-
Ignoring alert items may result in data inconsistency. Evaluate each alert carefully before ignoring it.
Step 6: Purchase the change tracking instance
-
Wait for Success Rate to reach 100%, then click Next: Purchase Instance.
-
On the Purchase page, select a billing method:
| Billing method | Description |
|---|---|
| Subscription | Pay upfront for a fixed duration. More cost-effective for long-term use. Available durations: 1–9 months, 1 year, 2 years, 3 years, or 5 years. Only Full-price Configuration Fee (No Data Traffic Fee) is available as the billing type. |
| Pay-as-you-go | Billed hourly. Best for short-term or unpredictable usage. Release the instance when no longer needed to avoid unnecessary charges. |
-
Optionally, assign the instance to a resource group. The default is default resource group. See What is Resource Management?
-
Read and select Data Transmission Service (Pay-as-you-go) Service Terms.
-
Click Buy and Start. The task appears in the task list — monitor its progress there.
What's next
After the change tracking task starts running, create consumer groups so your downstream clients can consume the tracked data.