Docs

Database Transmission Service

Volcano Engine RDS for MySQL as the source

Synchronizing to Volcano Engine RDS for MySQL

This topic describes how to create a task for synchronizing the Volcano Engine RDS for MySQL to Volcano Engine RDS for MySQL on the Database Transmission Service (DTS) console

Prerequisites

An instance and database for RDS for MySQL have been created. For details, refer to Creating an instance (RDS for MySQL) and Creating a database.

Confirm the network connectivity and service availability of the source and target databases before creating a data synchronization task.

The network connectivity and service availability of the source and destination have been confirmed.

Optional. Check each synchronization object in the source and target databases according to the instructions in the pre-check items. For more information, refer to Pre-check items (MySQL).

Precautions

When the target database uses a high-privilege account, DTS automatically creates the database in the target database. If the database name to be synchronized does not comply with the target database naming conventions, you need to create the database in the target database before the synchronization task.

During the database and table structure initialization, DTS synchronizes foreign keys from the source database to the target database.

During full initialization and incremental synchronization, DTS temporarily disables constraint checks and foreign key cascade operations at the Session level. When the task runs, if the source database has cascade update or delete operations, data inconsistency may occur.

During incremental synchronization, if the target database already has the same primary key value or unique value, you can select the conflict handling method for DTS based on business needs, such as overwrite on conflict, abort on conflict, or ignore on conflict.

During full initialization, if the target database already has the same primary key or unique value, DTS uses the conflict overwrite strategy, meaning the source data overwrites the target data.

When a conflict overwrite occurs, if there is a table with the same name in the target database, it may cause data inconsistency issues or task failures as detailed below. It is recommended to use table name mapping or delete or rename the table with the same name in the target database to avoid data inconsistency and reduce business risks.

When the table structure is consistent, data from full synchronization overwrites records in the target table with the same primary key or unique key values as in the source database.

When the table structure is inconsistent, initialization of data may fail, and only partial column data can be synchronized or synchronization may fail.

During synchronization, if there are CREATE TABLE or RENAME TABLE operations on the source end, select the entire database containing the table or the entire database where the table is renamed to when configuring the synchronization object. Otherwise, the newly created or renamed table will not synchronize to the destination.

Limits

Type	Description
Source database limits	Database version: MySQL 5.7 and 8.0 instances are supported. When the source database instance version is 5.6 or higher, gtid_mode and enforce_gtid_consistency must both be set to ON. tip When the MySQL version is earlier than 8.0 and the parameter gtid_mode is disabled, foreign key cascading deletion may fail during data synchronization, resulting in data differences. Bandwidth requirements: Adequate egress bandwidth is required on the source database server. Failure to meet this prerequisite will lead to suboptimal synchronization performance. Supports the InnoDB database storage engine. MariaDB database engine is not supported currently. Tables to be synchronized must have a primary key or a unique non-null constraint, and their fields must be unique. Otherwise, data inconsistency may occur. Binlogs must meet the following requirements: The Binlog feature must be enabled, and the parameter binlog_format set to row, binlog_row_image set to full. Otherwise, pre-check will report an error, and data synchronization tasks can not start successfully. Binlogs must be retained for at least 24 hours, and a retention period of more than seven days is recommended. Otherwise, the DTS task may fail because it cannot obtain the logs, potentially leading to data loss. Tables with foreign key dependencies must be synchronized together, or data synchronization will fail. It is recommended that the number of tables in a single task should not exceed 20,000, and the number of databases should not exceed 1,000. When a large number of databases and tables need to be synchronized, it is recommended to split them into multiple tasks.
Target database limits	Database version: MySQL 5.7 and 8.0 instances are supported. The synchronization account privileges of the target database will affect the use of views, stored procedures, and functions. The specific limits are as follows: When the synchronization account of the target database has SET_USER_ID permission, the limits for views, stored procedures, and functions are as follows: Views, stored procedures, and functions will retain the original definer and sql_security. The views, stored procedures, and functions can be used normally only after the account synchronization task is completed or the corresponding account is manually created in the target database. When the synchronization account of the target database does not have or support SET_USER_ID permission, after synchronizing views, stored procedures, and functions, the definer will be replaced by the synchronization account, and sql_security will be set to invoker. tip Only MySQL 8.0 supports setting SET_USER_ID permission.
DDL limitations	Operation limits General rules DDL operations are prohibited during initialization: Do not execute DDL statements during link creation, schema initialization, or full data synchronization—otherwise, the task will fail. When the target database is being written to by applications, executing DDL on the source may result in data loss. For example: unidirectional synchronization task: in a unidirectional incremental synchronization task, once application traffic has been switched over (i.e., writes have migrated to the destination), executing DDL operations on the source end is strictly prohibited. Otherwise, it may cause serious consequences such as data loss or schema inconsistency on the destination. At this stage, any DDL operations must be performed on the target database. The source database should be used only for synchronization backtracking or read-only queries. Bidirectional synchronization task:When both databases accept application writes, executing DDL on either side may cause data loss or schema inconsistency on the peer database. tip When using online DDL tools such as gh-ost or pt-online-schema-change, temporary tables are created during schema changes. Data written to the target database during operations like RENAME or DROP on these temporary tables may be lost. OnlineDDL support scope: Do not write data to the target database during DDL synchronization, as it may result in data loss. DTS supports synchronizing the following temporary tables (ensure the target database has write permissions): gh-ost: original table name _ghc, original table name _gho, original table name _del, tp_{change ID}_ogt_{original table name}, tp_{change ID}_g_{original table name} tp_{change ID}_del_{original table name}, tp_{change ID}_d_{original table name}. pt-osc: original table name _new, original table name _old. Table mapping (renaming) is mutually exclusive with Online DDL temporary table synchronization, only one can be enabled at a time. Even lightweight operations, such as adding a column to a small table, may cause DDL synchronization to fail if the temporary table exists for too short a duration. It is recommended to perform all such changes uniformly through DBW tickets. For detailed steps, refer to lock-free schema change tickets or lock-free data change tickets. Avoid frequent DDL operations: Repeatedly applying DDL to the same table may cause DTS metadata updates to fail, risking replication interruption. You can avoid this issue by: When performing DDL operations via the console, allow a minimum interval of 1–3 seconds between consecutive operations. Prefer using DBW lock-free schema change tickets to execute DDL operations. For detailed steps, refer to lock-free schema change tickets or lock-free data change tickets. Cross-Database DDL restrictions: If a database is not included in the synchronization objects, you must not execute DDL statements that affect already synchronized databases (e.g., cross-database views, foreign keys, etc.). Otherwise, the synchronization task will fail. DDL synchronization is currently supported only from the forward task to the target database; reverse DDL is not automatically synchronized. If reverse DDL synchronization is required, first adjust the DDL synchronization direction, then perform the operation. For detailed operations, refer to adjusting the DDL synchronization direction of the bidirectional synchronization task. Special limitations Table schema changes must be forward-compatible and limited to the following safe DDL operations:CREATE TABLE, ADD COLUMN, MODIFY COLUMN (only to increase column length), CREATE INDEX, DROP INDEX. Prohibited operations: Modifying column data types, dropping columns, or reducing column lengths are not allowed, as they may cause data inconsistency or replication interruption.
Bidirectional synchronization limits	When creating a bidirectional synchronization task, you need to pay attention to the following information: Data writing and conflict control Single-point write principle: for records with the same primary key, business key, or unique key, updates are allowed only on one node (source end or destination end). If both ends update the data simultaneously, the system will automatically resolve the conflict based on the primary key conflict resolution strategy configured in the task. It is recommended to avoid writing to the same primary key from both ends at the application layer. Do not write non-DTS data to the target database: During synchronization, do not write data to the target database via applications, scripts, or other tools, as this may cause primary key conflicts or data overwrites. Network and topology recommendations Outbound Cloud Link Performance Risk:If the synchronization involves data transfer from Volcano Engine to a public cloud (outbound), network bandwidth or latency may cause performance bottlenecks. Creating a bidirectional synchronization task directly is not recommended. Bidirectional synchronization consists of two independent unidirectional tasks (forward + reverse) that must be configured separately, with consistent filter rules and conflict resolution strategies.
Other limits	It is recommended that the source and target RDS for MySQL databases be the same version, or synchronize from a lower version to a higher one to ensure compatibility. Prior to executing data synchronization, assess the performance of both source and target databases. It is also advised to perform synchronization during off-peak business hours. Otherwise, during full data initiation, DTS consumes certain read/write resources on both source and target databases, which may lead to an increase in database load. During synchronization, the target database may generate a large number of Binlog files, causing the target database disk usage to be much higher than that of the original instance. It is recommended that you modify the storage policy of the target database Binlog before or during synchronization to avoid Binlog files from occupying too much storage space. For data synchronization tasks with database or table name mapping, the mapping may not take effect after the stored procedure and function are synchronized. If the source database is RDS for MySQL 8.0, when configuring synchronization tasks, you must manually grant the relevant data synchronization permissions directly to the following accounts: The accounts for the source or target database are granted relevant permissions through the Role. The accounts that need to perform User synchronization are granted relevant permissions through the Role. Synchronization tasks only support synchronizing tables, views, functions, and stored procedures.

Supported synchronization architectures

One-to-one unidirectional synchronization

One-to-many unidirectional synchronization

Many-to-one unidirectional synchronization

Cascading unidirectional synchronization

One-to-one bidirectional synchronization

For information on the types and usage of synchronization topology supported by DTS, refer to Data synchronization topology.

Supported SQL operations

Operation type	SQL statement
DML	INSERT, UPDATE, DELETE
DDL	ALTER TABLE, ALTER VIEW CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW DROP INDEX, DROP TABLE, DROP VIEW, DROP FUNCTION, DROP PROCEDURE RENAME TABLE TRUNCATE TABLE

Database account minimum permission policy

Database	Schema initialization	Full initialization	Incremental synchronization
Source database	SELECT permission	SELECT permission	REPLICATION SLAVE, REPLICATION CLIENT, and SELECT permissions.
Target database	Read/Write permissions	Read/Write permissions	Read/Write permissions

On the Create synchronization task page, locate the Configure source and target database wizard, and configure the following parameters.

Type	Name	Description
Basic information	Task name	Optional. Customize the task name. The length must be within 256 characters. tip If not set, the system generates a task name by default according to the naming rule, starting with dts-.
		Link specification	Select the link specifications for the synchronization task as needed. Compact, Medium, and Standard are supported. tip The link specification can not be modified after the task is successfully created. For details on the link specifications, refer to Product specifications.
		Synchronization topology	Select a synchronization topology based on your business needs. Unidirectional synchronization and Bidirectional synchronization are currently supported. tip Bidirectional synchronization currently only supports RDS for MySQL 5.6 and above. For more information about the synchronization topology, refer to Data synchronization topology.
Source database configuration	Select an existing data source	You can choose whether to use an existing instance as needed: Use existing instances: Click Select an existing data source, then in the Select data source control panel, choose the target region from the Region drop-down list, and select the target data source. Supports selecting data sources by data source name and ID. For methods to create data sources, refer to Data source management. Do not use existing instances: If not using an existing instance, you need to configure the following database instance information.
		Instance type	Select MySQL.
		Access method	Select Volcano Engine RDS for MySQL.
		Region	Select the region where the target instance is located.
		Cross-Volcano Engine account?	Select whether to transmit data cross-account as needed, with the following options: This account: Selecting this means data transmission occurs only within this account. Cross-account: Selecting this means data transmission occurs between two accounts. tip When transmitting data across accounts, log on to the Database Transmission Service (DTS) console through the account of the destination. Before cross-account data transmission, create and authorize an IAM role in the source root user. For detailed steps, refer to How to authorize users for cross-account data transmission.
		Cross-account ID	Enter the Volcano Engine account ID to which the source database belongs.
		Cross-account roles	Enter the IAM role authorized for DTS to access cross-account resources.
		MySQL instance	Select the target instance of RDS for MySQL from the drop-down list. tip You can also search for the target instance by instance ID or name.
		Node type	Select node types as needed, currently supporting Primary node and Read-only node. tip Select read-only nodes when read-only nodes are created within the instance. For specific steps on creating a read-only node, refer to Read-only node overview.
		MySQL read-only node	Select the target read-only node from the drop-down list. tip When a read-only node is created in the instance and Node type selects Read-only node, this parameter can be configured.
		Database account	Enter the database account of the target instance.
		Database password	Enter the password corresponding to the database account of the target instance.
		Test connection	Click Test connection to verify the connection to the instance. If the test connection fails, modify the configuration based on the failure prompt, and then click Test connection again to verify the connection. The details are as follows: Connection authentication failed. Check if the username and password are correct: When this error prompt appears, verify your username and password. Connection authentication failed, unable to create connection normally, contact customer service: When this error prompt appears, submit a ticket for technical support.
Target database configuration	Select an existing data source	You can choose whether to use an existing instance as needed: Use existing instances: Click Select an existing data source, then in the Select data source control panel, choose the target region from the Region drop-down list, and select the target data source. Supports selecting data sources by data source name and ID. For methods to create data sources, refer to Data source management. Do not use existing instances: If not using an existing instance, you need to configure the following database instance information.
		Instance type	Select MySQL.
		Access method	Select Volcano Engine RDS for MySQL.
		Region	Select the region where the target instance is located.
		MySQL instance	Select the target instance of RDS for MySQL from the drop-down list. tip You can also search for the target instance by instance ID or name.
		Database account	Enter the database account of the target instance.
		Database password	Enter the password corresponding to the database account of the target instance.
		Test connection	Click Test connection to verify the connection to the instance. If the test connection fails, modify the configuration based on the failure prompt, and then click Test connection again to verify the connection. The details are as follows: Connection authentication failed. Check if the username and password are correct: When this error prompt appears, verify your username and password. Connection authentication failed, unable to create connection normally, contact customer service: When this error prompt appears, submit a ticket for technical support.
Project and billing	Project	Optional. Select the affiliated project for the task from the drop-down list. By default, it is under default (default project). You can also click Create new project to create a new project. For more information, refer to Creating a new project. tip To grant sub-user privileges to access resources in a specific project, refer to Modifying project privileges. After a task is created successfully, if you need to change its affiliated project, you can move the resource to another project. A project is a virtual concept that includes a set of resources, users, and roles. A project allows for a unified view and management of a set of resources, and controls the permissions of users and roles within the project for those resources.
		Tag	(Optional) Click Add tag to add a tag to the instance. Tags can help you categorize cloud resources, control access to them, and allocate bills and costs. A tag is a key-value pair that identifies a cloud resource. You can use tags to categorize resources with the same characteristics from different dimensions, such as purpose or owner, making it easier to filter, aggregate, and manage your cloud resources. For more details about tags, refer to Tag overview. The rules for tag key-value pairs are as follows: Key Supports any language, characters, numbers, spaces, or symbols (_.:/=+-@). Case-sensitive, and the length is 1 to 128 characters. In UTF-8 encoded Unicode format. Keys cannot start with any form of volc:, such as Volc: or VOLC:. (Optional) Value Supports any language, character, digit, space, or symbol (_.:/=+-@). Case-sensitive, and the length is 0 to 256 characters. In UTF-8 encoded Unicode format. tip Support fuzzy search for selecting existing tag keys and tag values. A maximum of 20 tags can be associated with a task in a single operation. A maximum of 50 tags can be associated with a single task. For a single resource, tag keys must be unique, and each tag key can have only one value.
		Billing method	Select a billing method: Pay-as-you-go or Subscription. tip For detailed billing information, refer to Billing instructions.
		Subscription duration	Select the duration of the subscription as needed. tip When selecting Subscription in Billing method, you can set the purchase time and also check Automatic renewal. The system automatically renews before task expiration.

Click Next: configure synchronization object.

On the Configure synchronization object wizard page, configure the related parameter information as shown in the table below.

tip

If you do not need to start the synchronization task immediately, click Save in the lower-right corner of the page after configuring the synchronization object.

After saving, you will be redirected to the Synchronization task list page. The task status will be To be started, and you can configure the synchronization task at a suitable time. For configuration methods, refer to Configuring a synchronization task.

Name			Description
Synchronization type			Select the synchronization type as needed. Currently, User initialization, Schema initialization, Full initialization, and Incremental synchronization are supported. tip Incremental synchronization is selected by default. When you select Schema initialization or Full initialization, after the pre-check is completed, DTS will initialize the data of the objects to be synchronized from the source instance in the target instance, which serves as the basis for subsequent incremental data synchronization. If specified non-system accounts and their associated permissions need to be synchronized from the source database to the target database, select User initialization.
Migration user			Select the target accounts as needed, and set a new password in the New password (Optional) column. When migrating multiple users, click Batch change password to change all their passwords at once. Otherwise, the target account passwords will be the same as the source passwords.Batch change password tip This configuration is supported when Synchronization type is set to User initialization. During database synchronization, the synchronization of users and privileges needs to be handled separately. If some accounts in the source database do not support synchronization, firstly, ensure that your business operations are not affected by the absence of these accounts.
Conflict resolution strategy			During incremental synchronization, the processing method to be used when the target database encounters duplicate primary key values or unique values is as follows: Overwrite on conflict: During task execution, if the target database contains the same primary key or unique value, DTS will not retain the conflicting data at the destination. Instead, the source data will overwrite the target data. Ignore on conflict: During task execution, if the target database contains the same primary key or unique value, DTS will retain the conflicting data at the destination, and the source data will not overwrite the target data. warning Abort on conflict strategy means that during task execution, if the target database contains the same primary key or unique value, the task will report an error and stop, with the error message indicating the conflicting data. This strategy is currently in a whitelist feature; to use it, submit a ticket. During incremental synchronization, if the target database already has the same primary key or unique value, you can choose a conflict resolution strategy for Database Transmission Service (DTS) based on your business needs, such as overwrite on conflict or ignore on conflict. During full initialization, if the target database already has the same primary key or unique value, DTS uses the conflict overwrite strategy, meaning the source data overwrites the target data. When a conflict overwrite occurs, if there is a table with the same name in the target database, it may cause data inconsistency issues or task failures as detailed below. It is recommended to use table name mapping or delete or rename the table with the same name in the target database to avoid data inconsistency and reduce business risks. When the table structure is consistent, data from full synchronization overwrites records in the target table with the same primary key or unique key values as in the source database. When the table structure is inconsistent, initialization of data may fail, and only partial column data can be synchronized or synchronization may fail.
Synchronization starting point			Set to pull Binlog logs from a specified position or timestamp. The values are as follows: System default: The default is the task start time. Specify GTID: Enter the specified GTID in the input box, formatted as source_id:transaction_id. Set GTID_EXECUTED: Enter the specified GTID_EXECUTED in the input box, formatted as source_id:transaction_id. If multiple exist, separate them with commas (,). For how to obtain the instance's GTID_EXECUTED, refer to How to obtain the GTID_EXECUTED of the instance. Specify timestamp: Click the input box to select a date, click Select time to set the time point, then click OK. tip When Synchronization type selects Full initialization, this step is not supported. GTID and GTID_EXECUTED must be legal values from the source end. Otherwise, pre-check reports an error. When Synchronization type selects both Full initiation and Incremental synchronization, the Starting timestamp defaults to the current time point and can not be modified. When selecting Specify timestamp, the time you set must be later than the earliest Binlog time on the source end. If there is no corresponding time Binlog, the closest Binlog starting point will be selected.
Sync type selection			Select the operation types to synchronize. Currently, DML and DDL operation statements are supported for synchronization. The details are as follows: DML: Currently supports Delete, Insert, and Update. All DML operation statements are selected by default and can be adjusted as needed. DDL: Synchronizes Full DDL by default, meaning all DDL operation statements are synchronized. You can also click Custom DDL, with all DDL operation statements selected by default and adjustable as needed. If no DDL operation statements need to be synchronized, click Do not synchronize. tip For DDL operation statements supported by DTS during data synchronization, refer to Supported synchronized SQL.
Whether to enable foreign key check?			Select whether to enable foreign key check as needed. When enabled, the tool supports synchronizing cascading updates and deletes of foreign keys from the source, ensuring data integrity and consistency throughout the synchronization.
Synchronization object			Select the synchronization objects, such as tables, views, functions, or stored procedures, supporting queries of target objects via Normal search and Global search. At the same time, you can perform the following operations in the Selected object area: Rename databases or tables: Click the pencil icon next to the target database, table, or view to rename them. If the entire database is selected in the Synchronization object area, only the database name can be modified in the Selected object area, and the database cannot be expanded. Click Batch mapping to modify database or table names in bulk. For more information, refer to Database and table batch mapping. Filter and delete unnecessary targets: The search box in the Selected object area supports fuzzy search to batch delete unwanted databases, tables, and other targets. If Schema initialization is selected as the Synchronization type, you can then choose which specific target databases or tables to initialize in the Selected objects area. tip Regular expression search for target objects is supported in the Synchronization object or Selected object areas.
Advanced configuration	Selected databases and tables	Only support resetting the synchronization type, conflict strategy, and data filtering of synchronized tables separately as follows: Full initialization: When the synchronization type selects full initialization, it supports selecting or canceling full initialization of target tables as needed. Incremental synchronization: Incremental synchronization is selected by default. You can select or deselect incremental synchronization for target tables as needed. Conflict strategy: Set the conflict strategy for target tables as needed. Supported options are: Abort, Ignore, or Overwrite. For more information about conflict strategy, refer to the parameter description of conflict resolution strategy. When only full initialization is selected, modifying the conflict strategy is not supported. Full data filtering: Set filter rules on the target table's full data filtering columns as needed to improve migration performance. After completing the filter setup on the target table, click the verification statement to validate if the filter conditions are met. tip When an entire database is selected as the synchronization object and not expanded, any parameter settings will be applied at the database level. This feature is currently in beta testing. To use it, submit a ticket for technical support. Filter condition currently supported =, !=, <, >, <=, >=, in, is null, and, or.
		Whether to pre-synchronize trigger	Select whether to pre-synchronize triggers as needed, supporting the following options: No: DTS synchronizes triggers after incremental synchronization ends by default. Yes: DTS synchronizes triggers before incremental synchronization starts and adds control statements in the target database's triggers to prevent DTS from triggering them. tip This feature is released in allowlist. To use it, submit tickets to contact technical support. Parameters are supported only when all the following conditions are met. Synchronization type includes schema initialization and incremental synchronization. Synchronization objects include triggers.
		Trigger synchronization method	Select the pre-synchronize trigger synchronization method as needed, supporting the following options: Automatic synchronization: DTS automatically synchronizes triggers before incremental synchronization and adds control statements to the triggers in the target database to prevent DTS from triggering them. Manual trigger synchronization: DTS requires manual trigger synchronization before incremental synchronization and adds control statements to triggers in the destination database to prevent DTS from triggering them. tip This parameter can only be configured if whether to pre-synchronize triggers is set to yes.
		Enable transaction merging?	Enabling transaction merging optimizes synchronization tasks by combining multiple individual transactions, improving overall efficiency and performance while ensuring data consistency. When data synchronization occurs frequently with large volumes, enabling transaction merging enhances synchronization efficiency.
		Synchronization preferences	Select a synchronization preference policy as needed. The following options are supported: Performance first: It can increase the speed of existing data synchronization but may also lead to higher disk fragmentation and increased system load. It is recommended to reserve an additional 50% of storage space on the target end. Performance first applies to scenarios with high requirements for existing data synchronization speed, such as financial transactions, fast data collection, and real-time monitoring. Space first: The test space amplification rate is generally around 5%, which is suitable for scenarios with limited storage resources and relatively low requirements for data synchronization timeliness, such as data archiving, historical data backup, and log file synchronization.
		Post-schema synchronization	Select whether to synchronize triggers or events after incremental synchronization based on demand. The following options are supported: No: Database Transmission Service (DTS) does not synchronize triggers and events after incremental synchronization. Yes: Database Transmission Service (DTS) synchronizes triggers and events after incremental synchronization ends. tip This parameter is supported only when the following conditions are met. Synchronization type includes schema initialization. Synchronization objects include triggers or events. If both pre-synchronization trigger and post-schema synchronization are configured, the trigger will synchronize twice before and after the incremental synchronization task.
		Enable ETL configuration	Choose whether to enable the ETL function. For more information about ETL, refer to Introduction to ETL. Yes: indicates enabling ETL functions. After enabling ETL rules, click Quick configuration field mapping/filtering rules, configure synchronization objects in the Quick configuration field mapping/filtering rules dialog box, and click OK to quickly generate ETL statements. After enabling the ETL function, you can configure data processing ETL rules by referring to the DSL syntax. Enter the data processing ETL rules, i.e., the DSL script, in the Enter ETL statements or use ETL assistant to generate statements...text box, and click Validate syntax to verify whether the data processing statements are correct. You can also use the ETL assistant to generate ETL statements in natural language. In the upper-right corner of the ETL statement text box, click ETL assistant to input ETL requirements, and press Enter. After generating the ETL, copy the generated ETL statements into the ETL text box. The ETL assistant offers a variety of ETL statement generation capabilities. For more information, refer to ETL assistant capabilities. Click Debug to test the effects of the ETL rules you created. For details on debugging, refer to Verifying ETL rules via ETL Playground tool. No: indicates not enabling ETL functions.
		Error retry time	If a synchronization task fails due to a disconnection between the source and target databases, the system immediately retries connecting to them multiple times within the specified time. Value range: 600–86400, in seconds (s). The default value is 600 seconds.
		Enable millisecond-level delay monitoring	Enable or disable millisecond-level latency monitoring as needed. When enabled, it provides high-precision, full-link, proactive end-to-end latency measurement, effectively improving monitoring stability and sensitivity to abnormal conditions such as network interruptions and idle disconnections. When enabled, DTS writes heartbeat signals to the source database. The source end account must have SELECT, INSERT, and UPDATE permissions. You can also manually create a heartbeat table on the source database to enable millisecond-level latency monitoring. For detailed steps, see Manually create a heartbeat table.
		Full synchronization rate	Set the full synchronization rate as needed. To prevent high synchronization rates from affecting the source database's performance, adjust the following parameters based on the read and write pressure of the source and target databases accordingly: Rows synchronized per second: Enable and set the rows synchronized per second as needed. The default value is 100000, and the value range is 1-100000. Data volume to synchronize per second: Enable this option and set the data volume as needed. The default value is 25000, the value range is 1-25000, and the unit is KB. Synchronization task concurrency: Set the concurrency of synchronization tasks as needed. The default value is 8, and the valid range is 1 to 64. tip You can configure this parameter when selecting Synchronization type as Full initiation. An excessively high synchronization rate may affect the performance of the source database. Adjust appropriately based on the read and write pressure of the source and target databases.

Last updated: 2026.05.06 16:27:41