Aurora for MySQL to Aurora for MySQL

BladePipe supports data replication from Aurora for MySQL to Aurora for MySQL. View supported migration, sync, verification, and connector capabilities.

Target DataSource：

Aurora for MySQL

Connection

Basic Functions

Function	Description
Schema Migration	If the target schema does not exist, BladePipe will automatically generate and execute CREATE statements based on the source metadata and the mapping rule.
Full Data Migration	Migrate data by sequentially scanning data in tables and writing it in batches to the target database.
Incremental Data Sync	Sync of common DML like INSERT, UPDATE, DELETE is supported. UPDATE and DELETE for tables without primary keys are not synced by default (manual selection required).
Data Verification and Correction	Verify all existing data. Optionally, you can correct the inconsistent data based on verification results. Scheduled DataTasks are supported. For more information, see Create Verification and Correction DataJob.
Subscription Modification	Add, delete, or modify the subscribed tables with support for historical data migration. For more information, see Modify Subscription.
Position Resetting	Reset positions by file position or timestamp. Allow re-consumption of incremental data logs in a past period or since a specific Binlog file and position.
Table Name Mapping	Support the mapping rules, namely, keeping the name the same as that in Source, converting the text to lowercase, converting the text to uppercase, truncating the name by "_digit" suffix.
DDL Sync	ALTER TABLE ADD COLUMN, DROP COLUMN, MODIFY COLUMN, CHANGE COLUMN ADD INDEX RENAME TABLE CREATE TABLE (whole database sync) Table partitioning Other compatible DDLs
Metadata Retrieval	Retrieve the target metadata with filtering conditions or target primary keys set from the source table.

Advanced Functions

Function	Description
Removal of Target Data before Full Data Migration	Remove the existing data in the Target before running the Full Data Migration, applicable for DataJobs reruning and scheduled Full Data migrations.
Recreating Target Table	Recreate target tables before running the Full Data Migration, applicable for DataJobs reruning and scheduled Full Data migrations.
Incremental Data Write Conflict Resolution Rule	IGNORE: Ignore primary key conflicts (skip writing), REPLACE: Replace the entire row in case of primary key conflicts.
Handling of Zero Value for Time	Allow setting zero value for time to different data types to prevent errors when writing to the Target.
Bidirectional Sync	Support bidirectional data migration and sync (DML/DDL) with the loop prevented. For more information, see MySQL Bidirectional Sync.
Online DDL Compatibility	Support GH-OST, PT-OSC, Aliyun DMS Online DDL, PT_GHOST.
Scheduled Full Data Migration	For more information, see Create Scheduled Full Data DataJob.
Custom Code	For more information, see Custom Code Processing, Debug Custom Code and Logging in Custom Code.
Adding Virtual Columns	Support adding custom virtual columns with fixed values, such as region, ID, etc.
Setting Target Primary Key	Change the primary key to another field to facilitate data aggregation and other operations.
Data Filtering Conditions	Support data filtering using WHERE conditions, with SQL-92 as the SQL language. For more information, see Data Filtering.
Setting Update Conditions for Target	Set additional update conditions for UPDATE operations, used to resolve conflicts in bidirectional sync.

Limits

Limit	Description
MySQL Storage Engine	Support InnoDB, MyISAM, AWS XEngine. Other storage engines have not been tested yet.
MySQL Character Set	Support utf8, utf8mb4, latin1. Other encodings have not been tested yet.

FAQ

How to handle MySQL DataJob latency?
What to do when binary Log cannot be found in MySQL Source?
What to do when access to schema in MySQL Source is denied?

Tip: MySQL source-related FAQ also applies to MySQL-based DataSources.

Source

Prerequisites

Prerequisite	Description
Permissions for Account	See Permissions Required for MySQL/MariaDB.
Enabling Binlog	[mysqld] log-bin=mysql-bin # Enable Binlog binlog-format=ROW # Choose ROW mode binlog_row_image=FULL # Changes include all column data

Parameters

Parameter	Description
parseBinlogParallel	Number of threads for parallel parsing of Binlog in Incremental DataJobs.
parseBinlogBufferSize	Size of the circular buffer for parsing Binlog in Incremental DataJobs.
maxTransactionSize	Maximum number of data rows per transaction. If exceeded, the transaction will be split and flushed in parts.
limitThroughputMb	Limit the throughput of incremental Binlogs.
extraDDL	Support synchronization of additional DDL, including PT, GHOST, ALI_DMS, and PT_GHOST.
needJsonEscape	Escape special characters in JSON to be written to the target database.
fullDataSqlConditionEnabled	Add filtering conditions in SQL during source data scanning. It only works in Full Data migration.
srcTimeZone	Source time zone, e.g., +08:00, Asia/Shanghai, America/New_York, etc.

Tips: To modify the general parameters, see General Parameters and Functions.

Target

Prerequisites

Prerequisite	Description
Permissions for Account	See Permissions Required for MySQL/MariaDB.
Port Preparation	Allow the migration and sync node (Worker) to connect to the MySQL/MariaDB port (e.g., 3306).

Parameters

Parameter	Description
keyConflictStrategy	Strategy for handling primary key conflicts during write in Incremental DataTask: IGNORE: Ignore conflicts (default) REPLACE: Replace conflicts (optional)
dstWholeReplace	Convert INSERT and UPDATE operations into full row replacement in the Target.
deCycle	Enable filtering in bidirectional sync to filter DML/DDL with specific markers.
specialSqlMode	Set a specific SQL mode when initializing the connection between databases.
defaultGisSRID	Set the SRID for GIS data types.
dstTimeZone	Target time zone, e.g., +08:00, Asia/Shanghai, America/New_York, etc.
increParallelApplyStrategy	Parallel write strategy for relational databases in the Target: KEY: Parallel writing to partitions separated based on primary keys. TABLE: Parallel writing to partitions separated based on tables. KEY_UPGRADE_TABLE: Parallel writing to partitions separated based on primary keys. Upgrade the partition to a table if there is an update to the unique key.

Tips: To modify the general parameters, see General Parameters and Functions.