ApsaraDB RDS:Migrate from a self-managed Db2 database to ApsaraDB RDS for MySQL

Prerequisites

Before you begin, make sure that:

• The Db2 database version is 9.7 to 11.5

  DTS also supports migration from a Db2 for i database of version 7.3 or 7.4. Follow the same procedure for those versions.

• The available storage of the RDS instance is larger than the total size of the data in the Db2 database

Limitations

• DTS does not support data definition language (DDL) synchronization.

• If the source database name does not conform to ApsaraDB RDS naming conventions, create a database in the RDS instance before you configure the migration task.

• DTS uses read and write resources of both the source and destination databases during full data migration, which increases the load on both database servers. To avoid service disruption, migrate data during off-peak hours — for example, when CPU utilization on both databases is below 30%. Performance-related risks are higher when slow SQL queries exist, tables have no primary keys, or deadlocks occur in the destination database.

• If a migration task fails and DTS automatically resumes it, stop or release the task before switching workloads to the destination instance to prevent the source data from overwriting destination data.

• Incremental data migration relies on Db2's Change Data Capture (CDC) replication technology, which has its own restrictions. See General data restrictions for SQL Replication.

Billing

Migration types

Schema migration

DTS migrates the schemas of the required objects to the destination instance, including tables, indexes, and foreign keys.

Full data migration

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

Incremental data migration

After full data migration completes, DTS continuously syncs changes from the Db2 database to the RDS instance using CDC replication. This keeps both databases in sync and lets you switch workloads with minimal downtime.

How it works

To avoid migration failures caused by object dependencies, DTS migrates data in the following order:

1. Migrate table schemas and indexes.

2. Migrate full data.

3. Migrate foreign key schemas.

4. Migrate incremental data.

Required permissions

To create a database account and grant the required permissions:

• Db2 database: See Creating group and user IDs for a Db2 database installation (Linux and UNIX) and Authorities overview.

• RDS instance: See Create an accountModify account permissions and Modify the permissions of an account.

Enable archive logging for incremental migration

Skip this step if you are migrating only full data.

Before you configure the migration task, enable the archive logging feature for the Db2 database. See logarchmeth1 - Primary log archive method configuration parameter and logarchmeth2 - Secondary log archive method configuration parameter.

Configure and start the migration task

1. Log on to the DTS console.

   If you are redirected to the Data Management (DMS) console, click the icon in the to go to the previous version of the DTS console.

2. In the left-side navigation pane, click Data Migration.

3. On the Migration Tasks page, select the region where the RDS instance resides.

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

5. Configure the source and destination databases.

   Section	Parameter	Description
   N/A	Task name	DTS auto-generates a task name. Specify a descriptive name to identify the task. The name does not need to be unique.
   Source database	Instance type	Select User-Created Database with Public IP Address. For other instance types, set up the required network environment first. See Preparation overview.
   	Instance region	Not required for User-Created Database with Public IP Address. If the Db2 database has a whitelist configured, click Get IP Address Segment of DTS next to Instance Region to get the DTS CIDR blocks and add them to the whitelist.
   	Database type	Select DB2.
   	Hostname or IP address	Enter the endpoint used to connect to the Db2 database. In this example, use the public IP address.
   	Port number	Enter the Db2 service port. The default is 50000. The port must be accessible over the Internet in this example.
   	Database name	Enter the name of the database to migrate.
   	Database account	Enter the username of the account used to connect to the Db2 database. See Required permissions.
   	Database password	Enter the password for the account. After entering the password, click Test Connectivity to verify the parameters. Passed confirms the connection. If Failed appears, click Check and fix the issues.
   Destination database	Instance type	Select RDS Instance.
   	Instance region	Select the region where the RDS instance resides.
   	RDS instance ID	Select the RDS instance ID.
   	Database account	Enter the username of the account authorized to manage the destination database. See Required permissions.
   	Database password	Enter the password for the account. After entering the password, click Test Connectivity to verify the parameters. Passed confirms the connection. If Failed appears, click Check and fix the issues.
   	Encryption	Select Non-encrypted or SSL-encrypted based on your requirements. For SSL-encrypted, enable SSL encryption on the RDS instance before configuring the task. See Configure SSL encryption for an ApsaraDB RDS for MySQL instance. This parameter is available only in the Chinese mainland and Hong Kong (China) regions.

6. In the lower-right corner, click Set Whitelist and Next. DTS automatically adds its CIDR blocks to the whitelist of Alibaba Cloud database instances (such as ApsaraDB RDS for MySQL) and to the security group rules of Elastic Compute Service (ECS) instances hosting self-managed databases. For self-managed databases hosted on multiple ECS instances, manually add the DTS CIDR blocks to each instance's security group rules. For self-managed databases in on-premises data centers or from third-party cloud providers, manually add the DTS CIDR blocks to the database whitelist. See CIDR blocks of DTS servers.

   Warning

   Adding DTS CIDR blocks to a whitelist or security group exposes your database to potential security risks. Before proceeding, take preventive measures such as using strong credentials, restricting exposed ports, validating API calls, auditing whitelist and security group rules regularly, and removing unauthorized CIDR blocks. Alternatively, connect the database to DTS through Express Connect, VPN Gateway, or Smart Access Gateway (SAG).

7. Select the migration objects and migration types.

   Parameter	Description
   Migration types	Select Schema Migration and Full Data Migration for a one-time full migration. To minimize downtime, also select Incremental Data Migration. If incremental migration is not selected, avoid writing to the Db2 database during migration to maintain data consistency.
   Available	Select objects from Available and click the icon to move them to Selected. Select columns, tables, or databases as needed. By default, migrated object names remain the same in the destination database. Use the object name mapping feature to rename objects. See Object name mapping. Note that renaming an object may cause dependent objects to fail migration.
   Rename databases and tables	Use object name mapping to rename objects in the destination database. See Object name mapping.
   Retry time for failed connections	By default, DTS retries failed connections for 720 minutes. If DTS reconnects within that period, the migration task resumes. Otherwise, the task fails. During the retry period, you are charged for the DTS instance. Set the retry period based on your requirements and release the DTS instance promptly after migration completes.

8. Click Precheck.

   The migration task starts only after the precheck succeeds. If the precheck fails, click the icon next to each failed item to view details, fix the issues, and run the precheck again.

9. Click Next.

10. In the Confirm Settings dialog box, configure Channel Specification. Read and select Data Transmission Service (Pay-as-you-go) Service Terms.

11. Click Buy and Start.

    • Full data migration: Do not manually stop the task. Wait for it to complete automatically. Stopping it early may result in incomplete data in the RDS instance.

    • Incremental data migration: The task does not stop automatically. Stop it manually at an appropriate time — for example, during off-peak hours or before switching workloads to the RDS instance. To stop the task at the right moment:

      1. Wait until the progress bar shows Incremental Data Migration and The data migration task is not delayed.

      2. Stop writing to the source Db2 database for a few minutes. The progress bar may briefly show a latency value.

      3. Wait until Incremental Data Migration status returns to The data migration task is not delayed.

      4. Manually stop the migration task.

12. Switch your workloads to the RDS instance.