MySQL/TDSQL-C/MariaDB/Percona/TDSQL for MySQL Check Details
You need to configure the following parameter as required; otherwise, the system will report a warning during verification. The warning will not affect the migration task progress but will affect the business. You need to assess and determine whether to modify the parameters.
We recommend that you set max_allowed_packet
in the target database to a value greater than that in the source database.
Impact on the business: If the value of max_allowed_packet
in the target database is smaller than that in the source database, data cannot be written to the target database, leading to full migration failures.
Fix: Change the value of max_allowed_packet
in the target database to a value greater than that in the source database.
We recommend that you set max_allowed_packet
in the target database to a value greater than 1 GB.
Impact on the business: If the value of max_allowed_packet
is too large, more memory will be used, causing packet losses and inability to capture the SQL statements of large exception transaction packets. If the value is too small, program errors may occur, causing backup failures and frequent sending/receiving of network packets, which compromises the system performance.
Fix: Run the following command to modify the max_allowed_packet
parameter:
set global max_allowed_packet = 1GB
We recommend that you use the same character set for the source and target databases.
Impact on the business: If the character sets of the source and target databases are different, there may be garbled characters.
Fix: Run the following command to change the character sets of the source and target databases to the same one:
set character_set_server = 'utf8';
We recommend that you use an instance with 2-core CPU and 4 GB memory or higher specifications.
If you only perform full data migration, do not write new data into the source instance during migration; otherwise, the data in the source and target databases will be inconsistent. In scenarios with data writes, we recommend that you select full + incremental data migration to ensure data consistency in real time.
For lock-involved data export, you need to use the FLUSH TABLES WITH READ LOCK
command to lock tables in the source instance temporarily, but the MyISAM tables will be locked until all the data is exported. The lock wait timeout period is 60s, and if locks cannot be obtained before the timeout elapses, the task will fail.
For lock-free data export, only tables without a primary key are locked.
To avoid duplicate data, make sure that the tables to be migrated have a primary key or non-null unique key.
If the source database instance is a distributed database, such as TDSQL for MySQL, you need to create sharded tables in the target database in advance; otherwise, the source database tables will become non-sharded ones after being migrated.
If the target database is MySQL/MariaDB/Percona/TDSQL-C for MySQL/TDSQL for TDStore, you need to check the explicit_defaults_for_timestamp
parameter in the source and target databases. If it is set to OFF
in the source database or if it is set to ON
in both the source and target databases, the task will report a warning to remind you of not modifying this parameter when the task is running.
You need to check the COLUMN_DEFAULT
and IS_NULLABLE
attributes of tables in the full database/table structure export stage. If COLUMN_DEFAULT
is set to NULL
and IS_NULLABLE
is set to NOT NULL
for tables in the source database, the table structure will not be migrated or synced, because otherwise, the MySQL system will automatically add the default CURRENT_TIMESTAMP
parameter for the migrated or synced data of the TIMESTAMP type.
Was this page helpful?