Use Data Transmission Service (DTS) to migrate data from an OceanBase database (MySQL-compatible mode, Community Edition V4.x) to a PolarDB for MySQL cluster. DTS supports schema migration, full data migration, and incremental data migration for this migration path.
Prerequisites
Before you begin, ensure that you have:
-
A source OceanBase database running Community Edition V4.x
-
A destination PolarDB for MySQL cluster with storage capacity larger than the source database. See Purchase an Enterprise Edition cluster and Purchase a subscription cluster
Constraints
Source database constraints
-
The source database cannot be an ApsaraDB for OceanBase database.
-
The source database server must have sufficient outbound bandwidth. Insufficient bandwidth reduces migration speed.
-
Tables to be migrated must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate records.
-
If you select tables as the migration objects and need to rename tables or columns in the destination database, a single task can migrate up to 1,000 tables. Migrating more than 1,000 tables in a single task causes a request error. In this case, split the migration into multiple tasks or migrate the entire database instead.
-
Data of the GEOMETRY type can only be migrated using full data migration. Incremental data migration is not supported for this type.
-
Column names in a MySQL database are case-insensitive. If the source database has multiple columns whose names differ only in capitalization, DTS migrates data from these columns into the same destination column, which may produce unexpected results.
Other constraints
-
DTS does not support converting data from the DATETIME type to the VARCHAR type.
-
Throttling is not available for full data migration.
-
If the source database name does not comply with PolarDB for MySQL naming conventions, create the destination database in the PolarDB for MySQL cluster before configuring the migration task. Then use the object name mapping feature to rename it in the Configure Objects and Advanced Settings step. For naming conventions and how to create a database, see Database Management.
-
For columns of the FLOAT or DOUBLE type, DTS applies
ROUND(COLUMN,PRECISION)to retrieve values. If no precision is specified, DTS defaults to 38 digits for FLOAT and 308 digits for DOUBLE. Verify that these defaults meet your business requirements. -
DTS automatically retries failed tasks for up to seven days. Before switching workloads to the destination database, stop or release any failed tasks, or run
REVOKEto remove DTS write permissions on the destination database. Otherwise, a resumed task may overwrite destination data with source data. -
If a DDL statement fails to execute in the destination database, the DTS task continues running. View failed DDL statements in the task logs. For details, see View task logs.
Operational restrictions
Apply these restrictions during migration to prevent data inconsistency:
-
During schema migration and full data migration: Do not run Data Definition Language (DDL) operations that change the schemas of databases or tables.
-
During full-data-only migration: Do not write data to the source database. To ensure data consistency throughout the migration, select schema migration, full data migration, and incremental data migration together.
-
During full and incremental data migration: DTS temporarily disables foreign key constraint checks and cascade operations at the session level. Performing cascade or delete operations on the source database during this period may cause data inconsistency.
-
RENAME TABLE operations: Renaming a table during incremental migration can cause data inconsistency. If you need to rename a table, add the databases containing the table before and after the rename operation to the migration objects.
Schema migration migrates foreign keys from the source database to the destination database.
Billing
| Migration type | Task configuration fee | Data transfer fee |
|---|---|---|
| Schema migration and full data migration | Free | Free in this example |
| Incremental data migration | Charged | — |
For incremental data migration pricing, see Billing overview.
SQL operations supported for incremental migration
| Operation type | SQL statements |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE |
Required database account permissions
| Database | Schema migration | Full data migration | Incremental data migration |
|---|---|---|---|
| OceanBase (user level) | SELECT | SELECT | SELECT |
| OceanBase (tenant level) | Regular tenant | Regular tenant | Regular tenant |
| PolarDB for MySQL | Read and write on the destination database | Read and write on the destination database | Read and write on the destination database |
For incremental data migration, install oblogproxy on the OceanBase server and configure a system tenant. oblogproxy is a proxy service for managing incremental logs. For installation instructions, see Install and deploy oblogproxy by using the installation package.
For instructions on creating accounts and granting permissions, see:
-
OceanBase: Create a tenant, Create a user, and Grant privileges
-
PolarDB for MySQL: Create and manage a database account
Migrate data from OceanBase to PolarDB for MySQL
Step 1: Go to the Data Migration Tasks page
-
Log on to the Data Management (DMS) console.
-
In the top navigation bar, click DTS.
-
In the left-side navigation pane, choose DTS (DTS) > Data Migration.
Navigation may vary based on the DMS console mode and layout. For details, see Simple mode and Customize the layout and style of the DMS console. You can also go directly to the Data Migration Tasks page in the new DTS console.
Step 2: Select the region
From the drop-down list next to Data Migration Tasks, select the region where the data migration instance resides.
In the new DTS console, select the region in the upper-left corner of the page.
Step 3: Configure source and destination databases
Click Create Task. On the Create Task wizard page, configure the following parameters.
Source database
| Parameter | Description |
|---|---|
| Select an existing DMS database instance | (Optional) Select an existing instance to auto-populate source database parameters. If you skip this, configure the parameters below manually. |
| Database Type | Select ApsaraDB OceanBase for MySQL. |
| Access Method | Select the access method based on where the source database is deployed. This example uses Public IP Address. |
| Instance Region | The region where the source OceanBase database resides. |
| Domain Name or IP | The endpoint of the source OceanBase database. |
| Port Number | The service port of the source OceanBase database. Default: 2881. |
| IP Address in Log Proxy (Domain Name Not Supported) | The IP address of oblogproxy for the source OceanBase database. |
| Port in Log Proxy | The listening port of oblogproxy. Default: 2983. |
| Database Account | The source OceanBase database account. For required permissions, see Required database account permissions. |
| Database Password | The password for the database account. |
| Task Name | A name for the task. DTS auto-assigns a name; specify a descriptive name to make the task easy to identify. The name does not need to be unique. |
If the source database is self-managed, set up the required environment before migration. For details, see Preparation overview.
Destination database
| Parameter | Description |
|---|---|
| Select an existing DMS database instance | (Optional) Select an existing instance to auto-populate destination database parameters. If you skip this, configure the parameters below manually. |
| Database Type | Select PolarDB for MySQL. |
| Access Method | Select Alibaba Cloud Instance. |
| Instance Region | The region where the destination PolarDB for MySQL cluster resides. |
| PolarDB Cluster ID | The ID of the destination PolarDB for MySQL cluster. |
| Database Account | The database account for the destination cluster. For required permissions, see Required database account permissions. |
| Database Password | The password for the database account. |
| Encryption | (Optional) Enable SSL encryption for the connection to the destination cluster. For details, see Configure SSL encryption. |
Step 4: Test connectivity
Click Test Connectivity and Proceed.
If the source database uses an IP address whitelist, add the CIDR blocks of DTS servers to the whitelist before clicking Test Connectivity and Proceed.
-
Alibaba Cloud database instances (such as ApsaraDB RDS for MySQL or ApsaraDB for MongoDB): DTS adds its CIDR blocks automatically.
-
Self-managed databases on ECS: DTS adds its CIDR blocks to the ECS security group rules automatically. Ensure that the ECS instance can access the database. If the database spans multiple ECS instances, add the CIDR blocks to each instance manually.
-
Self-managed databases in a data center or on a third-party cloud: Add the CIDR blocks manually to the database IP address whitelist.
For the list of DTS server CIDR blocks, see Add the CIDR blocks of DTS servers.
Adding DTS CIDR blocks to a database whitelist or ECS security group introduces security exposure. Before proceeding, take measures such as using strong credentials, restricting exposed ports, authenticating API calls, auditing whitelist rules regularly, and connecting via Express Connect, VPN Gateway, or Smart Access Gateway.
Step 5: Configure objects and migration settings
| Parameter | Description |
|---|---|
| Migration Types | Select the migration types based on your scenario:
|
| Processing Mode of Conflicting Tables |
|
| Capitalization of Object Names in Destination Instance | Controls capitalization of database, table, and column names in the destination. Default is DTS default policy. For details, see Specify the capitalization of object names in the destination instance. |
| Source Objects | Select objects from Source Objects and click the arrow icon to move them to Selected Objects. You can select columns, tables, or databases. Selecting tables or columns excludes views, triggers, and stored procedures. |
| Selected Objects | To rename a single object, right-click it in Selected Objects. See Map the name of a single object. To rename multiple objects at once, click Batch Edit. See Map multiple object names at a time. To filter rows, right-click an object to specify WHERE conditions. See Set filter conditions. To select specific SQL operations for incremental migration, right-click an object and select the operations. |
Object name mapping may cause data inconsistency or break objects that depend on the renamed object. For example, non-full table migration with column mapping can result in data loss if source columns are absent in the destination schema.
Step 6: Configure advanced settings
Click Next: Advanced Settings and configure the following parameters.
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | By default, DTS schedules tasks to a shared cluster. To improve stability, purchase a dedicated cluster. See What is a DTS dedicated cluster. |
| Set Alerts | Configure alerting for task failures or migration latency that exceeds a threshold. Select Yes to set an alert threshold and notification contacts. See Configure monitoring and alerting. |
| Select the engine type of the destination database | The storage engine for the destination PolarDB for MySQL cluster: InnoDB (default) or X-Engine (an online transaction processing (OLTP) storage engine). |
| Retry Time for Failed Connections | How long DTS retries a failed connection before marking the task as failed. Range: 10–1440 minutes. Default: 720. Set to at least 30 minutes. If different tasks share the same source or destination database, the most recently set value applies. During retries, DTS instance charges still apply. |
| Retry Time for Other Issues | How long DTS retries failed DDL or DML operations. Range: 1–1440 minutes. Default: 10. Set to at least 10 minutes. Must be smaller than Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Limit the migration speed to reduce load on the source and destination databases. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s). Available only when Full Data Migration is selected. |
| Enable Throttling for Incremental Data Migration | Limit incremental migration speed. Configure RPS of Incremental Data Migration and Data migration speed for incremental migration (MB/s). Available only when Incremental Data Migration is selected. |
| Environment Tag | An optional tag to identify the DTS instance. |
| Configure ETL | Enable extract, transform, and load (ETL) to process data during migration. Select Yes and enter processing statements in the code editor. See Configure ETL in a data migration or data synchronization task. |
During full data migration, DTS uses read and write resources on both the source and destination databases, which increases server load. Run migrations during off-peak hours. After full data migration completes, concurrent INSERT operations may cause table fragmentation in the destination database, so the destination tablespace will be larger than the source.
Step 7: Run the precheck
Click Next: Save Task Settings and Precheck.
To preview the API parameters for this task configuration before saving, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.
DTS runs a precheck before starting the migration task. The task can only start after the precheck passes.
-
If a precheck item fails, click View Details next to the failed item to see the cause, fix the issue, and run the precheck again.
-
If a precheck item generates an alert, handle it based on the scenario:
-
If the alert cannot be ignored, click View Details next to the failed item, troubleshoot the issues, and run the precheck again.
-
If the alert can be safely ignored, click Confirm Alert Details, then click Ignore in the View Details dialog box, click OK, and click Precheck Again.
-
Ignoring a precheck alert may cause data inconsistency or other issues. Proceed with caution.
Step 8: Purchase the DTS instance
Wait until the success rate reaches 100%, then click Next: Purchase Instance.
On the Purchase Instance page, configure the following:
| Section | Parameter | Description |
|---|---|---|
| New Instance Class | Resource Group Settings | The resource group for the migration instance. Default: default resource group. See What is Resource Management? |
| Instance Class | The instance class determines migration speed. Select based on your requirements. See Specifications of data migration instances. |
Step 9: Start the migration task
Read and select the Data Transmission Service (Pay-as-you-go) Service Terms check box, then click Buy and Start. Monitor task progress in the task list.
FAQ
What values do I enter for oblogproxy fields if oblogproxy is not installed?
Use the default values for IP Address in Log Proxy (Domain Name Not Supported) and Port in Log Proxy. Do not select Incremental Data Migration for Migration Types — selecting it without oblogproxy installed causes an error.
The region of my source OceanBase database is not in the Instance Region drop-down list. What do I select?
Select the region closest to where your source OceanBase database is located.
My source OceanBase database is deployed in a cluster. What do I enter for Domain Name or IP?
Enter the value you specified for OBServer Node when you created the cluster.
What Port Number do I enter for the source OceanBase database?
-
Standalone deployment: use the default value (2881).
-
Cluster deployment: enter the value you specified for SQL Port when you created the cluster.
What format does Database Account use for the source OceanBase database?
Use the <Username>@<Tenant name> format. For example, if the user is dtstest in the tenant dts, enter dtstest@dts.