You may need to change the character set of a table based on your business requirements. For example, you may need to change the character set from GBK to UTF8mb4. However, an ALTER statement that is used to change the character set of a large table will lock the table and cause negative impacts on your business.
This topic describes how to change the character set without affecting your business. You can create a table schema in the destination instance based on the new character set, and then use Data Transmission Service (DTS) to migrate table data to the destination instance. To further ensure service continuity, you can prepare a rollback solution or a dual-write solution.
Usage notes
- Before you change the character set, make sure that your business system and SQL statements are compatible with the new character set and the features of the business system will not be affected.
- During full data migration, DTS uses read/write resources of the source and destination instances. This may increase the database load. Before you migrate data, evaluate the performance of the source and destination instances. We recommend that you migrate data during off-peak hours.
- The source instance must have PRIMARY KEY or UNIQUE constraints and all fields must be unique. Otherwise, duplicate data may exist in the destination instance.
Step 1: Import the table schema from the source instance to the destination instance
In this example, the management mode of the instances that you log on to by using Data Management (DMS) is Flexible Management.
- Export the script of the source table schema from the source instance. The source table schema refers to the schema of the table whose character set you want to change.
- Decompress the exported file, and change the character set in the script of the table schema.
- Create an ApsaraDB RDS for MySQL instance of the same type as the source instance. The new instance is the destination instance. For more information about how to create an ApsaraDB RDS for MySQL instance, see Create an ApsaraDB RDS for MySQL instance.
- Import the edited script of the table schema to the new ApsaraDB RDS for MySQL instance.
Step 2: Migrate table data from the source instance to the destination instance
- Log on to the DTS console. Note
- If you are navigated to the DMS console, you can move your mouse over the
icon in the lower-right corner and click the
icon to go to the DTS console of the previous version.
- If you are navigated to the DTS console of the new version, you can click the
icon in the lower-right corner to go to the DTS console of the previous version.
- If you are navigated to the DMS console, you can move your mouse over the
- In the left-side navigation pane, click Data Migration.
- At the top of the Migration Tasks page, select the region where the destination cluster resides.
- In the upper-right corner of the page, click Create Migration Task.
- Configure the source and destination databases.
Section Parameter Description Task Name - The task name that DTS automatically generates. We recommend that you specify a descriptive name that makes it easy to identify the task. You do not need to specify a unique task name. Source Database Instance Type The type of the source database. Select RDS Instance. Instance Region The region in which the source instance resides. RDS Instance ID The ID of the source ApsaraDB RDS for MySQL instance. Database Account The database account of the source ApsaraDB RDS for MySQL instance. The account must have the read/write permissions on the database to be migrated. Database Password The password of the database account of the ApsaraDB RDS for MySQL instance. Note After you specify the information about the self-managed Oracle database, you can click Test Connectivity next to Database Password to check whether the information is valid. If the information is valid, the Passed message appears. If the Failed message appears, click Check next to Failed. Then, modify the information based on the check results.Encryption Specifies whether to encrypt the connection to the source instance. Select Non-encrypted or SSL-encrypted. If you select SSL-encrypted, you must enable SSL encryption for the ApsaraDB RDS for MySQL instance before you configure the data migration task. For more information, see Configure SSL encryption for an ApsaraDB RDS for MySQL instance. Note The Encryption parameter is available only for regions in the Chinese mainland.Destination Database Instance Type The type of the destination database. Select RDS Instance. Instance Region The region in which the destination ApsaraDB RDS for MySQL instance resides. RDS Instance ID The ID of the destination ApsaraDB RDS for MySQL instance. Database Account The database account of the destination ApsaraDB RDS for MySQL instance. The account must have the read/write permissions on the destination database. Database Password The password of the database account of the ApsaraDB RDS for MySQL instance. Note After you specify the information about the destination database, you can click Test Connectivity next to Database Password to check whether the information is valid. If the information is valid, the Passed message appears. If the Failed message appears, click Check next to Failed. Then, modify the information based on the check results.Encryption Specifies whether to encrypt the connection to the destination instance. Select Non-encrypted or SSL-encrypted. If you select SSL-encrypted, you must enable SSL encryption for the ApsaraDB RDS for MySQL instance before you configure the data migration task. For more information, see Configure SSL encryption for an ApsaraDB RDS for MySQL instance. Note The Encryption parameter is available only for regions in the Chinese mainland. - In the lower-right corner of the page, click Set Whitelist and Next. Note The CIDR blocks of DTS servers are automatically added to the whitelist of the source and destination ApsaraDB RDS for MySQL instances. This ensures that DTS servers can connect to the source and destination ApsaraDB RDS for MySQL instances.
- Select the migration types and objects to be migrated.
Parameter Description Migration Types Schema migration is completed in Step 1. Therefore, you do not need to select Schema Migration in this step. - To perform only full data migration, select only Full Data Migration. Warning To ensure data consistency, we recommend that you do not write data to the source instance during full data migration.
- To ensure service continuity during data migration, select Full Data Migration and Incremental Data Migration. Note The following SQL operations can be migrated during incremental data migration: INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, and DROP TABLE.
Select the objects to be migrated In the Available section, select the objects whose schema has been migrated in Step 1, and click the icon to add the objects to the Selected Objects section.
Warning We recommend that you do not use the object name mapping feature. Otherwise, the data migration task fails. - To perform only full data migration, select only Full Data Migration.
- Start the migration task.
Step 3: Switch your workloads
Switch your workloads by using one of the following solutions:
- Rollback solution: You do not need to edit the code of your application. However, a rollback failure may occur.
- After data migration is complete, verify the data in the destination ApsaraDB RDS for MySQL instance.
- Prepare a rollback solution, and then switch your workloads to the destination instance. The rollback solution is based on a data migration task in the opposite direction. The task allows you to switch workloads back to the original source instance. For more information, see Switch workloads to the destination database.
- Test the features of your business. If the features work as expected, delete the data migration task in the opposite direction.
- Optional:If you no longer need the source ApsaraDB RDS for MySQL instance, release the instance.
- Dual-write solution: This solution ensures a high success rate of rollback. However, great efforts are required to edit your application code.
- Edit the application code to implement the dual-write solution. The dual-write solution writes data changes to both the source and destination instances.
- Stop the data migration task.
- Full data migration
Do not manually stop a task during full data migration. Otherwise, the system may fail to migrate all data. Wait until the migration task automatically ends.
- Incremental data migration
The task does not automatically end during incremental data migration. You must manually stop the migration task.
- Wait until the task progress bar shows Incremental Data Migration and The migration task is not delayed. Then, stop writing data to the source database for a few minutes. In some cases, the progress bar shows the delay time of incremental data migration.
- After the status of incremental data migration changes to The migration task is not delayed, manually stop the migration task.
Note Make sure that no sessions are performing write operations. To retrieve session information, you can log on to the source instance and execute theshow processlist;
statement. - Full data migration
- After data migration is complete, verify the data in the destination ApsaraDB RDS for MySQL instance.
- Enable the dual-write solution for your application. Then, data changes will be written to both the source and destination instances.
- Test the features of your business on the destination instance. If the features work as expected, disable the dual-write solution.
- Optional:If you no longer need the source ApsaraDB RDS for MySQL instance, release the instance.