Category | Description |
Synchronization object | 1. Only basic tables and views are supported for synchronization; objects such as functions, triggers, and stored procedures are not supported. 2. Associated data objects need to be synchronized at the same time. Otherwise, synchronization will fail. 3. A source TDSQL for MySQL instance can contain up to 5,000 tables. Exceeding this limit will cause Data Transfer Service (DTS) tasks to report errors. Additionally, an excessive number of tables can increase access latency on the source, resulting in performance jitter and degradation. 4. During the incremental synchronization phase, table names containing TDSQLagent or tdsql_sub in the source database may be filtered or cause synchronization exceptions. These names conflict with temporary tables of the TDSQL system: TDSQLagent is used during scale-out, while tdsql_sub tables are child tables for hash-list and hash-range. Therefore, it is recommended to avoid using such table names for synchronization. |
Impact on the source database | 1. When DTS is used to perform a full data synchronization task, it occupies certain resources of the source database, which may cause the source database load to increase and add pressure to the database. If your database configuration is low, it is recommended to operate during off-peak hours. 2. During data synchronization, DTS uses the account for executing the synchronization task to write to the system database __tencentdb__ in the source database. This database is used to record metadata such as transaction marker IDs. It is necessary to ensure that the source database account has read/write permissions for __tencentdb__.To ensure that data comparison issues can be traced later, the __tencentdb__ database in the source will not be deleted after the synchronization task ends.The __tencentdb__ system database occupies minimal space, approximately 0.01% to 0.1% of the source database's storage capacity. For example, for a 50 GB source database, the __tencentdb__ system database is approximately 5 MB–50 MB. It employs a single-threaded, connection-waiting mechanism, thus having a negligible impact on source database performance and not preempting any resources.3. By default, a lock-free synchronization method is adopted. During the full data export phase, no global lock (FTWRL) is applied to the source database; only table-level locks are applied to tables without primary keys. |
Synchronization feature description | 1. The current policy for handling primary key conflicts supports only overwriting. When primary key conflicts occur during either the full or incremental synchronization phase, the overwriting policy applies. 2. The constraints for DDL operations are as follows: During the full export phase, do not perform DDL operations that change database or table structures in the source database. During the incremental synchronization phase with a TDSQL for MySQL distributed instance as the source, it is recommended to avoid executing highly concurrent DDL operations within a short period, as this may cause latency or link interruptions. 3. Only the InnoDB database engine is supported for synchronization. If other database engines are used, the task will report errors during checks. 4. During incremental synchronization, modifying primary keys is not supported. This includes changes to primary key columns, shard keys in partitioned tables, COMMENT annotations on primary key columns, and operations that add, delete, or modify columns or their lengths. 5. During incremental synchronization, if binlog statements in STATEMENT format are generated in the source database, data synchronization will fail. 6. Synchronizing the entire source instance is not supported. If a database creation operation (CREATE DATABASE) is performed at the source during the subsequent synchronization task, it is recommended that you manually create the corresponding database object at the target before starting the synchronization task. 7. If the CREATE TABLE or RENAME TABLE operation is performed at the source during a synchronization task, you should select the entire database where the table resides when selecting synchronization objects during the configuration phase. Otherwise, the newly created or renamed tables will not be synchronized to the target. |
Operation restrictions | Do not perform the following operations during synchronization. Otherwise, they will cause the synchronization task to fail. 1. Do not modify or delete user information (including usernames, passwords, and permissions) and port numbers in the source and target databases during the synchronization task. 2. Do not perform binlog cleanup operations on the source database. |
Data type | 1. Geometry-related data types are not supported. Such data will cause task errors. 2. For tables containing floating-point data types, precision differences between full and incremental synchronization may lead to precision inconsistencies in the synchronized data. 3. When the source TDSQL for MySQL uses the MariaDB 10.1.x kernel, specifying precision for the timestamp type (such as timestamp(3)) is not supported. Otherwise, the DTS task will report an error. You need to remove the precision and then recreate the task. |
Transaction | 1. A single transaction cannot contain both DML and DDL statements at the same time. Such transactions will cause task errors. 2. When the source database is TDSQL for MySQL (MariaDB 5.6 kernel), eXtended Architecture (XA) transactions are not supported. XA transactions will cause the task to fail. |
High availability (HA) switch and scale-out | 1. If the source database is a non-global transaction identifier (GTID) database, DTS does not support an HA switch on the source. If a switch is performed on the source TDSQL for MySQL, the DTS incremental synchronization may be interrupted. 2. If the source database is a self-built database using SET nodes to connect to TDSQL for MySQL, any addition or deletion of SET nodes during synchronization will cause DTS task errors. Users need to modify the SET configuration information of the source database in the DTS task (to keep it consistent with the actual SET configuration of the source) and then restart the task. Only in this way can the information about the added or deleted SET nodes be synchronized. |
Partitioned table synchronization | 1. The full synchronization phase supports synchronization of primary/secondary partitioned tables, but the partitioning syntax needs to comply with TDSQL for MySQL specifications. Primary Hash partitioned tables can only be created through the shardkey method. The key syntax for creating partitioned tables in TDSQL for MySQL is as follows. For detailed syntax, see TDSQL for MySQL Official Documentation. 1.1 Primary partition Primary Hash partition: shardkey Primary Range partition: TDSQL_DISTRIBUTED BY RANGE Primary List partition: TDSQL_DISTRIBUTED BY LIST 1.2 Secondary partition Primary Hash partition + Secondary Range/List partition: shardkey + PARTITION BY RANGE/LIST Primary Range partition + Secondary Range/List partition: TDSQL_DISTRIBUTED BY RANGE + PARTITION BY RANGE/LIST Primary List partition + Secondary Range/List partition: TDSQL_DISTRIBUTED BY LIST + PARTITION BY RANGE/LIST 1.3 New secondary partition Primary Hash partitioning + Secondary Range/List partitioning: TDSQL_DISTRIBUTED BY HASH + TDSQL_PARTITION BY RANGE/LIST 2. During incremental synchronization, frequently creating, dropping, and recreating secondary partitioned tables is not supported, as this may cause task exceptions due to table type conflicts. Additionally, dropping non-existent secondary partitioned tables before creating new ones may result in deadlocks, where the task reports no errors but requires manual unlocking. 3. When synchronization is performed from TDSQL for MySQL to MySQL/MariaDB/Percona, if the source databases or tables contain secondary partitioned tables, they will be converted to single tables on the target. |
Specify Start Checkpoint | If Initialization Type is not specified, it indicates that only incremental synchronization is performed, and you can set the start checkpoint for incremental synchronization. Currently, you need to submit a ticket to apply for using this feature. 1. The incremental synchronization task starts synchronizing data from the set time point. The time point can be set within the range from the previous 14 days to the current time. 2. If full and incremental migrations are performed as separate tasks, ensure that no DDL operations (such as CREATE TABLE, ALTER TABLE, DROP TABLE, RENAME TABLE, CREATE INDEX, and DROP INDEX) occur between time point 1, when the full migration completes, and the set time point 2 for incremental migration. Otherwise, the task will report an error. 3. From the set time point 1 to the start point 2 of the incremental task (the task is considered started only after the task step changes from searching for the specified checkpoint to synchronizing increments). The must-knows for operations on the source database are as follows. It is recommended that you do not perform a primary-secondary switch, add shards, or recreate secondary servers on the source database; otherwise, it may affect the ability of DTS to obtain the GTID checkpoint of the source database. You can perform DDL operations that are not related to the synchronization objects on the source. However, ensure that the previous DDL operation has been synchronized to the target before you execute a new one. Executing DDL operations too frequently may cause task errors. You cannot perform DDL operations related to the synchronization objects (such as CREATE TABLE, ALTER TABLE, DROP TABLE, RENAME TABLE, CREATE INDEX, and DROP INDEX) on the source; otherwise, the synchronization task will report an error. 4. Point-in-time synchronization determines the GTID based on the timestamp specified in the binlog context (SET TIMESTAMP=XXXX). To ensure data synchronization accuracy, it is recommended that users not modify this context. 5. Ensure that the time zone set in the database is consistent with the current console time zone (that is, the browser time zone), or convert the time to the database time zone. Otherwise, the synchronization results for the specified checkpoint may differ from expectations. 6. Ensure that the time is consistent across all cluster nodes in TDSQL for MySQL; otherwise, the synchronization results for the specified checkpoint may differ from expectations. 7. If the set time point falls within the duration of an XA transaction, that XA transaction will not be synchronized. In this case, it is recommended to set the time point earlier (before the XA START time). 8. When the point-in-time feature is used, gtid_mode must be set to ON on the source. |
フィードバック