The following parameters must be configured as required; otherwise, the system will issue warnings during validation. Although these warnings do not interrupt the migration task, they may adversely affect business operations. We recommend that users evaluate the impact and decide whether to modify them.
1. It is recommended that the max_allowed_packet setting in the target database be greater than that in the source database.
Business impact: If the max_allowed_packet parameter setting in the target database is smaller than that in the source database, data will fail to be written to the target database, resulting in the failure of full data migration.
Handling suggestion: Modify the max_allowed_packet parameter setting in the target database to be greater than that in the source database.
2. It is recommended that the max_allowed_packet setting in the target database be greater than 1GB.
Business impact: If the max_allowed_packet setting is too large, it will consume more memory and cause packet loss, preventing the capture of abnormally large transaction packets SQL. If the setting is too small, it may trigger error reporting in applications, cause backup failures, and result in frequent network packet transmission/reception, thereby degrading system performance.
Handling suggestion: Refer to the following command to modify the max_allowed_packet parameter.
set global max_allowed_packet = 1024;
3. It is recommended that the character set of the source database and the target database remain consistent.
Business impact: If the character sets of the source database and the target database are inconsistent, it may result in garbled characters.
Handling suggestion: Refer to the following command to modify the character sets of both the source database and the target database to be consistent.
set character_set_server = 'utf8';
4. It is recommended that the sql_mode settings of the source database and the target database remain consistent; otherwise, abnormal synchronization results may occur.
Should any inconsistencies arise, see the following method to modify them to be consistent.
SET GLOBAL sql_mode = 'new_SQL_mode';
5. It is recommended to use instances with specifications of 2 CPU and 4000 MB Mem or higher.
6. If only performing full data migration, do not write new data to the source instance during the migration process; otherwise, it will cause inconsistency between the source and target data. For scenarios with data write operations, to maintain data consistency in real time, it is recommended to choose full + incremental data migration.
7. During locked export: The source instance will briefly lock using Flush Table With Read Lock, and MyISAM tables will remain locked until the full data export is completed. The current lock acquisition timeout is set to 60 seconds. Failure to obtain the lock within this period will cause the task to fail.
8. During unlocked export: A read lock is applied only to tables without a primary key, and no lock is applied to others.
9. For tables that have neither a primary key nor a non-null unique key, there is a risk of data duplication. It is recommended that users define a primary key or a non-null unique key for the tables being migrated.
10. For TDSQL MySQL data migration, when the source database instance is a distributed database, sharded tables must be created in the target database in advance; otherwise, these tables will become single tables after migration.
11. When the target database is MySQL/MariaDB/Percona/TDSQL-C MySQL/TDSQL Boundless, check the explicit_defaults_for_timestamp settings of the source and target databases. If the source database is OFF, or both source and target are ON, the task will issue a warning to remind users not to modify this parameter arbitrarily during task execution.
12. During the full export of database table structures, check the COLUMN_DEFAULT and IS_NULLABLE attributes of the tables. If the COLUMN_DEFAULT of a source table is NULL and IS_NULLABLE is NOT NULL, the table structure will not be migrated/synchronized. This is to prevent the MySQL system from automatically adding the default parameter "CURRENT_TIMESTAMP" to the TIMESTAMP data type after data synchronization to the target database.
13. Starting from MySQL 8.0, the thread pool feature (Thread Pool) is supported. If the thread pool feature is enabled on the target database (indicated by the thread_handling parameter not being set to one-thread-per-connection in the MySQL configuration file), the target database's thread_pool_size parameter must be greater than or equal to 16 to enhance concurrent write performance. If the value is less than 16, this check item will issue a warning, reminding users of potential write performance issues.