Data Transmission Service:Migrate a PolarDB for MySQL cluster across accounts

Usage notes

• 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%.

• If the source database contains tables without primary keys or unique constraints, and the columns are not unique, duplicate data may appear in the destination database.

• If a migration task fails, DTS automatically attempts to resume it. Before you switch your business to the destination database, you must stop or release the task. This prevents the resumed task from overwriting destination data with source data.

Migration types

Billing

SQL operations for incremental migration

Permissions required for database accounts

Before you begin

1. Log on to the Alibaba Cloud Management Console with the Alibaba Cloud account that owns the source PolarDB for MySQL cluster.
2. Create a RAM role and grant it permission to access the source account's cloud resources. For more information, see Configure RAM authorization for cross-account data migration from a self-managed database in a VPC.
   Note DTS does not directly support cross-account migration for PolarDB for MySQL clusters. This method uses a workaround by treating the source PolarDB for MySQL cluster as a self-managed database connected over an Express Connect circuit. Alternatively, you can apply for a public endpoint for the source cluster and migrate it as a self-managed database with a public IP address. This alternative does not require creating a RAM role or configuring authorization.

Procedure

1. Log on to the DTS console with the Alibaba Cloud account that owns the destination PolarDB for MySQL cluster.

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

3. At the top of the Migration Tasks page, select the region of the destination cluster.

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

5. For Instance Type, select User-Created Database Connected over Express Connect, VPN Gateway, or Smart Access Gateway, and then select VPC of Another Alibaba Cloud Account.
   Note DTS does not directly support cross-account migration for PolarDB for MySQL clusters. This method uses a workaround by treating the source PolarDB for MySQL cluster as a self-managed database connected over an Express Connect circuit. Alternatively, you can apply for a public endpoint for the source cluster and migrate it as a self-managed database with a public IP address.
6. Configure the source and destination databases.

   Category	Parameter	Description
   N/A	Task Name	DTS automatically generates a task name. We recommend using a descriptive name for easy identification. The name does not need to be unique.
   Source Database	Instance Type	Select User-Created Database Connected over Express Connect, VPN Gateway, or Smart Access Gateway.
   	Instance Region	Select the region where the source PolarDB for MySQL cluster is located.
   	Alibaba Cloud Account ID	Enter the ID of the Alibaba Cloud account that owns the source PolarDB for MySQL cluster. Note You can obtain the account ID by logging on to the Account Management page with the Alibaba Cloud account that owns the source PolarDB for MySQL cluster. In the left-side navigation pane of Account Center, choose Basic Information. You can then view the Account ID.
   	Role Name	Enter the name of the RAM role that you created in the Before you begin section.
   	Peer VPC	Select the VPC where the source PolarDB for MySQL cluster resides. You can log on to the PolarDB console by using the Alibaba Cloud account that owns the source PolarDB for MySQL cluster, and then click the cluster ID to go to the Basic Information page of the cluster. On the Basic Information page, the VPC ID is the value in the VPC field (for example, vpc-bp...).
   	Database Type	Select MySQL.
   	IP Address	Enter the private IP address of the primary endpoint for the source PolarDB for MySQL cluster. In this example, enter 172.16.20.20. PolarDB for MySQLYou can obtain the private IP address by pinging the source cluster's VPC-facing endpoint. On the Basic Information page of the PolarDB cluster, find the Connection Information section. In the Primary Endpoint card, copy the VPC-facing endpoint, which has a format similar to pc-bp1xxxxx.polardb.rds.aliyuncs.com:3306.
   	Port	Enter the service port of the source PolarDB for MySQL cluster. The default port is 3306.
   	Database Account	Enter the database account of the source PolarDB for MySQL cluster. For permission requirements, see Permissions required for database accounts.
   	Database Password	Enter the password for the 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, the message Passed is displayed. If the message Failed is displayed, click Diagnose next to the Failed message and adjust the source database information based on the prompts.
   Destination Database	Instance Type	Select PolarDB.
   	Instance Region	Select the region where the destination PolarDB for MySQL cluster is located.
   	PolarDB Instance ID	Select the ID of the destination PolarDB for MySQL cluster.
   	Database Account	Enter the database account of the destination PolarDB for MySQL cluster. For permission requirements, see Permissions required for database accounts.
   	Database Password	Enter the password for the database account. Note After you enter the destination database information, you can click Test Connectivity after Database Password to verify that the entered information is correct. If the information is correct, a Passed message is displayed. If a Failed message is displayed, click Diagnose after Failed and adjust the destination database information based on the prompts.

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

   For Alibaba Cloud database instances like ApsaraDB RDS for MySQL or ApsaraDB for MongoDB, DTS automatically adds its server CIDR blocks to the instance's whitelist. For a database self-hosted on an ECS instance, DTS adds the CIDR blocks to the security group rules automatically. For clusters on multiple ECS instances, or for databases in an on-premises data center or on a third-party cloud, you must manually add the CIDR blocks to allow access. For a list of required CIDR blocks, see CIDR blocks of DTS servers.

   Warning

   Adding the public CIDR blocks of DTS servers, whether automatically or manually, may introduce security risks. By using this product, you acknowledge and accept these potential risks. You are responsible for implementing basic security measures, including but not limited to using strong passwords, restricting open ports, using authentication for internal API calls, regularly reviewing and restricting unnecessary network segments, or connecting through private networks such as Express Connect, VPN Gateway, or Smart Access Gateway.

8. Select the migration types and objects.

   

   Setting	Description
   Migration types	To perform only a full migration, select both Schema Migration and Full Data Migration. To perform a zero-downtime migration, select Schema Migration, Full Data Migration, and Incremental Data Migration. Important If you do not select Incremental Data Migration, do not write new data to the source database during the full data migration to ensure data consistency.
   Migration objects	In the Available box, click the objects that you want to migrate and click the icon to move them to the Selected Objects box. Important You can select objects to migrate at the database, table, and column levels. By default, object names are retained after migration. If you need to rename an object in the destination database, use the object name mapping feature. For more information, see Object name mapping. If you rename an object by using the object name mapping feature, other objects that depend on it may fail to migrate.
   Object name mapping	If you need to rename a migrated object in the destination instance, use the object name mapping feature. For more information, see Object name mapping.
   Connection retry duration	If a connection to the source or destination database is interrupted, DTS retries to connect for a default of 720 minutes (12 hours). You can customize this duration. If DTS successfully reconnects within the specified time, the migration task resumes. Otherwise, the task fails. Note You are charged for the DTS instance while it attempts to reconnect. To avoid unnecessary charges, set an appropriate retry duration or release the DTS instance promptly if the source and destination databases are released.
   Replicate temporary tables created during online DDL operations in DMS	If you use Data Management (DMS) to perform online DDL operations on the source database, you can choose whether to migrate the temporary tables that are generated. Yes: Migrates the data in the temporary tables that are generated by online DDL operations. Note If a large amount of temporary table data is generated by online DDL operations, the migration task may experience high latency. No: Does not migrate the data in the temporary tables. Only the original DDL data from the source database is migrated. Note This option may cause table locks on the destination database.

9. After you complete the configuration, click Precheck and Start in the lower-right corner of the page.

   Note

   • Before the migration task starts, DTS runs a precheck. 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 as prompted and run the precheck again.

     • If you do not need to fix the warning items, you can select Ignore and then click Ignore Warnings and Rerun Precheck to run the precheck again.

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

11. In the Confirm Settings dialog box that appears, select a Instance Class and select the Data Transmission Service (pay-as-you-go) Service Terms checkbox.

12. Click Buy and Start to begin the migration.

    • Schema migration + Full data migration

      Allow the task to complete automatically. Stopping it manually may result in incomplete data.

    • Schema migration + Full data migration + Incremental data migration

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

      Important

      Choose an appropriate time to stop the task manually, such as during off-peak hours or when you are ready to switch your business to the destination cluster.

      1. Wait until the migration task enters the Incremental Data Migration phase and the status shows Undelayed. Then, stop writing data to the source database for several minutes. During this time, the status of Incremental Data Migration may show a latency.

      2. Wait for the Incremental Data Migration status to show Undelayed again. Then, manually stop the migration task.