Data Transmission Service:Migrate from self-managed Db2 to ApsaraDB RDS for MySQL

Prerequisites

• The source Db2 database is version 9.7 to 11.5.

  Note

  DTS also supports migrating Db2 7.3 and 7.4 to ApsaraDB RDS for MySQL. The configuration is similar.

• The destination ApsaraDB RDS for MySQL instance must have more storage space than the source Db2 database.

Limitations

• Data definition language (DDL) operations are not synchronized.

• If a source database name does not comply with ApsaraDB RDS naming conventions, create a database with a compliant name in the destination instance before configuring the migration task.

  Note

  For naming conventions and creation steps: Create a database and accounts.

• A full data migration consumes read and write resources on both the source and destination databases, increasing their server load. This added load can degrade performance or cause service unavailability, especially if your databases have poor performance, low specifications, or are already busy (for example, with many slow SQL queries, tables without primary keys, or deadlocks in the destination database). Before you start the migration, evaluate the performance of both databases and perform the migration during off-peak hours, for example, when CPU utilization is below 30%.

• Stop or release the migration task before switching your business to the destination instance. Otherwise, an automatic task resumption overwrites data in the destination instance.

• DTS uses the Change Data Capture (CDC) replication technology of Db2 to synchronize incremental data updates to the destination database. However, this technology has limitations. General data restrictions for SQL Replication.

Billing

Migration types

• Schema migration

  DTS migrates schema definitions (tables, indexes, and foreign keys) to the destination instance.

• Full data migration

  DTS migrates all existing data from the source Db2 database objects to the destination instance.

• Incremental data migration

  After full data migration, DTS synchronizes incremental data updates from the source Db2 database to the destination instance, enabling smooth migration with minimal downtime.

Database account permissions

To create database accounts and grant permissions:

• Db2 database:Creating users and Authorities.

• ApsaraDB RDS for MySQL instance: Create a database and accounts and Change the permissions of a standard account.

Data migration process

Prepare for incremental data migration

Enable archive logging for the Db2 database before configuring incremental data migration. Primary log archive method and Secondary log archive method.

Procedure

1. Log on to the Data Transmission Service (DTS) console.

   Note

   If you are automatically redirected to the Data Management (DMS) console, you can click the icon in the lower-right corner and then click to return to the classic DTS console.

2. In the navigation pane on the left, click Data Migration.

3. At the top of the Migration Tasks page, select the region where the destination instance is located.

4. In the upper-right corner of the page, click Create Data Migration Task.

5. Configure the source and destination databases.

   Section	Parameter	Description
   N/A	Task name	DTS auto-generates a task name. Use a descriptive name for easy identification. Uniqueness is not required.
   Source Database	Instance type	Select the source database deployment. This example uses User-Created Database with Public IP Address. Note If your self-managed database is a different instance type, you must perform additional preparations. For more information, see Preparations.
   	Instance region	If you select User-Created Database with Public IP Address as the instance type, you do not need to set the Instance Region parameter. Note If a whitelist is configured for the Db2 database, click Get IP Address Segment of DTS next to the Instance Region parameter to obtain DTS server CIDR blocks and add them to the Db2 whitelist.
   	Database type	Select DB2.
   	Hostname or IP address	Enter the public IP address or hostname of the source Db2 database.
   	Port	Enter the service port of the Db2 database. The default port is 50000. Note The service port must be publicly accessible in this example.
   	Database name	Enter the name of the database to migrate.
   	Database account	Enter the Db2 database account with the permissions described in Database account permissions.
   	Database password	Enter the password for the Db2 database account. Note After you enter the source database information, you can click Test Connectivity next to Database Password to verify that the information is correct. If the information is correct, a Passed message is displayed. If a Failed message is displayed, click Diagnose next to Failed, and adjust the source database information as prompted.
   Destination Database	Instance type	Select RDS Instance.
   	Instance region	Select the region of the destination RDS instance.
   	RDS instance ID	Select the ID of the destination RDS instance.
   	Database account	Enter the destination RDS account with the permissions described in Database account permissions.
   	Database password	Enter the password for the account. Note After you enter the information for the destination database, you can click Test Connectivity next to Database Password to verify the entered information. If the information is correct, a Passed message is displayed. If a Failed message is displayed, click Diagnose next to Failed and adjust the destination database information based on the prompts.
   	Connection method	Select Non-encrypted or SSL-encrypted. If you select SSL-encrypted, you must first enable SSL encryption for the RDS instance. Configure SSL encryption. Note The Encryption parameter is available only in the China (Hong Kong) region and regions in the Chinese mainland.

6. Click Set Whitelist and Next in the lower-right corner.

   Note

   DTS automatically adds its server CIDR blocks to the destination RDS instance whitelist.

7. Select the migration types and migration objects.

   Parameter	Description
   Migration types	To perform only full migration, select Schema Migration and Full Data Migration. To migrate with minimal downtime, select Schema Migration, Full Data Migration, and Incremental Data Migration. Note If you do not select Incremental Data Migration, avoid writing to the source database during migration to ensure data consistency.
   Migration objects	In the Migration Objects section, click the objects that you want to migrate and then click the icon to move them to the Selected Objects section. Note You can select objects at the database, table, or column level. By default, migrated object names remain the same as in Db2. To rename objects in the target RDS instance, use DTSObject name mapping. Object name mapping may cause dependent object migrations to fail.
   Rename mapped objects	To rename migration objects in the target instance, useObject name mapping.
   Retry duration upon connection failure	Default: 12 hours (customizable). If DTS reconnects to both databases within this period, the task resumes automatically. Otherwise, the task fails. Note DTS charges continue during retry. Set a reasonable duration based on your needs, or release the DTS instance after the source and destination instances are released.

8. After you complete these settings, click Pre-check and Start in the lower-right corner of the page.

   Note

   • DTS performs a precheck before the task starts. The task can start only after it passes the precheck.

   • If the precheck fails, click the icon next to the failed item to view details.

     • Fix the issues based on the details, and then run the precheck again.

     • For warnings that do not require a fix, you can select Ignore or Ignore and Rerun Precheck to run the precheck again.

9. After the task passes the precheck, click Next.

10. On the Confirm Order page, select a Instance Class and select the Data Transmission Service (Pay-As-You-Go) Terms of Service checkbox.

11. Click Buy and Start. The migration task starts.

    • Full data migration

      Do not manually stop the migration task. This can cause data loss. Wait for the task to finish. The task stops automatically.

    • Incremental data migration

      The migration task does not stop automatically. You must stop it manually.

      Note

      Stop the task manually at a suitable time, such as during off-peak hours or when you are ready to switch your business to the destination instance.

      1. Wait until the task status changes to Incremental Data Migration and shows Undelayed. Then, stop writing data to the source database for a few minutes. The status of Incremental Data Migration may show a latency.

      2. Wait until the status of Incremental Data Migration changes back to Undelayed. Then, stop the migration task manually. The progress of schema migration and full data migration both show 100%. To pause the migration task, select the task and click Pause in the batch operations bar at the bottom.

12. Switch your business to the ApsaraDB RDS for MySQL instance.