ApsaraDB RDS:Migrate self-managed Db2 to ApsaraDB RDS for MySQL

Prerequisites

• The version of the source Db2 database is 9.7 to 11.5.

  Note

  DTS also supports migrating Db2 databases of versions 7.3 and 7.4 to ApsaraDB RDS for MySQL. The configuration process is similar to what is described in this topic.

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

Usage notes

• DTS does not synchronize DDL operations.

• If a source database name does not follow the naming conventions for ApsaraDB RDS, you must create a compliant database in the destination ApsaraDB RDS for MySQL instance before you configure the migration task.

  Note

  For more information about naming conventions and how to create a database, see Create a database on an ApsaraDB RDS for MySQL instance.

• During a full data migration, DTS consumes read and write resources on the source and destination databases, increasing their load. If your databases have poor performance, low specifications, or high workloads (for example, if the source database has many slow SQL queries or tables without primary keys, or if deadlocks occur in the destination database), the increased load can strain your databases or even cause service interruptions. Perform the data migration during off-peak hours, such as when the CPU utilization of both databases is below 30%.

• To prevent the source database from overwriting data in the destination instance, stop or release the task before you switch your business to the destination instance.

• DTS uses Db2's Change Data Capture (CDC) technology to replicate incremental data. However, CDC has limitations on supported data types. For more information, see General data restrictions for SQL Replication.

Billing

Migration types

• Schema migration

  DTS migrates the schema definitions of objects to the destination instance. DTS supports schema migration for tables, indexes, and foreign keys.

• Full data migration

  DTS migrates all historical data from the selected objects in the source Db2 database to the destination ApsaraDB RDS for MySQL database.

• Incremental data migration

  After the full migration, DTS replicates data changes from the source Db2 database to the destination ApsaraDB RDS for MySQL database. This enables a smooth migration from your self-managed database with minimal downtime.

Database account permissions

To create database accounts and grant permissions, see the following documentation:

• For the self-managed Db2, see Creating users and Authorities overview.

• For the ApsaraDB RDS for MySQL instance, see Create an account on an ApsaraDB RDS for MySQL instance and Modify the permissions of a standard account on an ApsaraDB RDS for MySQL instance.

Data migration process

Preparations for incremental data migration

Before you configure an incremental data migration task, you must enable archive logging for the Db2 database. For more information, see 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 automatically generates a task name, but you can choose a more descriptive, non-unique name for easier identification.
   Source Database	Instance Type	Select an instance type based on where your source database is deployed. This topic uses User-Created Database with Public IP Address as an example. Note If your self-managed database is of a different instance type, you may need to complete additional preparations. For more information, see Preparations for data migration.
   	Instance Region	If you select User-Created Database with Public IP Address for Instance Type, you do not need to set the Instance Region parameter. Note If your Db2 database uses a whitelist, click Get DTS IP CIDR Blocks next to the Instance Region parameter to get the DTS IP CIDR blocks and add them to the whitelist of your Db2 database.
   	Database Type	Select DB2.
   	Hostname or IP Address	Enter the endpoint of the Db2 database. In this example, a public IP address is used.
   	Port	Enter the service port of the Db2 database. The default is 50000. Note In this example, the service port must be accessible over the Internet.
   	Database Name	Enter the name of the database to be migrated.
   	Database Account	Enter the database account for the Db2 database. For permission requirements, see Database account permissions.
   	Database Password	Enter the password for the Db2 database account. Note After configuring the source database, you can click Test Connectivity next to Database Password to verify that DTS can connect. If the connection test passes, a Passed message appears. If it Failed, click Diagnose next to the Failed message and modify the settings 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 database account for the destination RDS instance. For permission requirements, see Database account permissions.
   	Database Password	Enter the password for the database account. Note After configuring the destination database, you can click Test Connectivity next to Database Password to verify that DTS can connect. If the connection test passes, a Passed message appears. If it Failed, click Diagnose next to the Failed message and modify the settings as prompted.
   	Connection Method	Select Non-encrypted or SSL-encrypted. If you select SSL-encrypted, you must first enable SSL encryption on the RDS instance. For more information, see Configure SSL encryption. Note The Encryption parameter is available only for regions in the Chinese mainland and the China (Hong Kong) region.

6. After you complete the settings, click Set Whitelist and Next in the lower-right corner of the page.

   Note

   In this step, the DTS IP CIDR blocks are automatically added to the whitelist of the destination RDS instance to ensure that the DTS servers can connect to it.

7. Select the migration types and objects.

   Parameter	Description
   Migration Types	To perform only a one-time migration, select Schema Migration and Full Data Migration. To perform a migration with minimal downtime, select Schema Migration, Full Data Migration, and Incremental Data Migration. Note If you do not select Incremental Data Migration, do not write new data to the source Db2 database during the migration to ensure data consistency.
   Migration Objects	In the Available box, select the objects that you want to migrate, and then click the icon to move them to the Selected Objects box. Note You can select objects at the database, table, or column level. To rename an object in the destination RDS instance, use the object name mapping feature. For details, see object name mapping. If you use the object name mapping feature, the migration of other objects that depend on the renamed object may fail.
   Rename mapped objects	To change the names of migrated objects in the destination instance, use the object name mapping feature. For more information, see object name mapping.
   Retry duration for source/destination connection loss	The default retry duration is 12 hours. You can customize this duration. If DTS reconnects to the databases within this duration, the task automatically resumes. Otherwise, it fails. Note You are charged for the DTS task while it is retrying to connect. We recommend that you set a reasonable retry duration based on your business needs or release the DTS instance as soon as possible 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 task. Wait for it to complete automatically to avoid data loss.

    • Incremental data migration

      The task does not stop automatically. Stop it manually.

      Note

      Stop the task during off-peak hours or when you are ready to switch 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 applications to the ApsaraDB RDS for MySQL instance.