Help Center/ DataArts Studio/ User Guide/ DataArts Migration (Real-Time Jobs)/ Using Real-Time Migration Jobs/ Configuring a Job for Synchronizing Data from MySQL to LakeFormation
Updated on 2026-09-14 GMT+08:00

Configuring a Job for Synchronizing Data from MySQL to LakeFormation

Supported Source and Destination Database Versions

Table 1 Supported database versions

Source Database

Destination Database

MySQL database (5.6, 5.7, and 8.x)

LakeFormation instances of version 25.12.0 or later that support the Iceberg table management feature

Database Account Permissions

Before you use DataArts Migration for data synchronization, ensure that the source and destination database accounts meet the requirements in the following table. Different types of synchronization tasks require different permissions. For details, see Table 2.

Table 2 Database account permissions

Type

Required Permissions

Source database connection account

The source database account must have the following minimal permissions required for running SQL statements: SELECT, SHOW DATABASES, REPLICATION SLAVE and REPLICATION CLIENT.

GRANT SELECT, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'Username'@'Resource group network segment', 'Username'@'IP address of the CDM cluster as an agent';

Destination database connection account

The LakeFormation connection must adapt to the AK/SK of the IAM user. The IAM user must have the following permissions:

  • Metadata operation permissions: LakeFormation stores the source data of tables. The IAM user must have the permissions to operate the LakeFormation schemas, databases, and tables. For details, see Planning LakeFormation Metadata.
  • Data write permissions: Data will be written to the OBS storage system. The IAM user must have the OBS read and write permissions. For details, see Planning LakeFormation Metadata.
  • You are advised to create independent database accounts for DataArts Migration task connections to prevent task failures caused by password modification.
  • After changing the account passwords for the source or destination databases, modify the connection information in Management Center as soon as possible to prevent automatic retries after a task failure. Automatic retries will lock the database accounts.

Supported Synchronization Objects

Table 3 lists the objects that can be synchronized in different scenarios.

Table 3 Synchronization objects

Type

Note

Synchronization objects

  • The following DML operations can be synchronized: INSERT, UPDATE, and DELETE.
  • The following DDL operations can be synchronized: deleting tables, adding columns, deleting columns, renaming tables, renaming columns, changing the column type, and clearing tables.
  • Only primary key tables can be synchronized.
  • Only MyISAM and InnoDB tables can be synchronized.
  • Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, and unique indexes cannot be synchronized.
  • Table structures, common indexes, constraints (primary key, null, and non-null), and comments can be synchronized during automatic table creation.
  • Foreign keys that contain reference operations such as CASCADE, SET NULL, and SET DEFAULT cannot be synchronized. These operations will cause the update or deletion of rows in parent tables and affect records in child tables. Also, operations related to child tables are not recorded in Binlogs.

Important Notes

In addition to the constraints on supported data sources and versions, connection account permissions, and synchronization objects, you also need to pay attention to the notes in Table 4.

Table 4 Important notes

Type

Usage and Operation Constraint

Database constraints

  • The names of the source databases, tables, and fields cannot contain non-ASCII characters or the following characters: .<'>/\" (You are advised to use common characters to avoid a failure.)
  • The name of an object in the destination database must contain 1 to 63 characters, start with a letter or underscore (_), and can contain letters, digits, underscores (_), and dollar signs ($).

Usage constraints

General:

  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • The source database cannot be restored.
  • Binlogs must be enabled for the source database and the value of binlog_row_image must be full.
  • It is recommended that MySQL binlogs be retained for more than three days. Binlogs cannot be forcibly cleared.

    When a job is restored after an exception or suspension, the recorded binlog location may expire. As a result, the job fails to be restored. It is important to monitor the duration of job exceptions or suspensions and the binlog retention period.

  • During real-time synchronization, the source MySQL database cannot be upgraded across major versions. Otherwise, data may become inconsistent or the synchronization task may fail (data, table structures, and keywords may cause compatibility changes after the cross-version upgrade). You are advised to create a synchronization task again if the source MySQL database is upgraded across major versions.

Full synchronization phase:

During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

Incremental synchronization phase:

  • During incremental synchronization, DDL operations (for example, ALTER TABLE ddl_test ADD COLUMN c2 AFTER/FIRST c1;) for adding columns to a specified position are not supported. The AFTER/FIRST attribute will be deleted, which may cause column sequence inconsistency.
  • During incremental synchronization, executing non-idempotent DDL statements (for example, ALTER TABLE ddl_test ADD COLUMN c3 timestamp default now();) may cause data inconsistency.
  • During incremental synchronization, database-level synchronization does not support online DDL operations, and table-level synchronization supports only online DDL operations generated by DMS on some clouds.
  • During incremental synchronization, the following DDL operations can be synchronized: creating tables, deleting tables, adding columns, deleting columns, renaming tables, renaming columns, changing the column type, and clearing tables. You can select the DDL types to be synchronized as needed.
    • The name of a table or column to be added or modified can contain no more than 63 characters. Otherwise, the job will fail.
    • During incremental migration, when CHANGE COLUMN is executed in the source database to modify a column which is a distribution column in the destination LakeFormation database, an exception may occur because distribution columns in LakeFormation databases cannot be modified.

Extraction from the standby database:

Before extracting data from the standby database, ensure that a value can be returned after the SHOW MASTER STATUS command is executed on the standby database node. Otherwise, data jobs may be abnormal and data may be lost when the jobs are suspended and then resumed.

Troubleshooting:

If any problem occurs during task creation, startup, full synchronization, incremental synchronization, or completion, rectify the fault by referring to FAQs.

Other

  • During real-time migration, Iceberg partition columns must be included in the primary key column so that upsert operations can be performed. Since the primary key cannot contain NULL values, the selected partition columns cannot contain NULL values either.
  • Currently, DDL synchronization supports only the addition of columns and their normal synchronization to the destination LakeFormation. Other DDL operations cannot be synchronized to the destination LakeFormation.
  • Iceberg primary keys do not support float, double, or non-basic data types. For details, visit the official website.
  • Currently, the supported destination LakeFormation Iceberg table is MANAGERD_TABLE. Metadata is stored in LakeFormation, and data is stored in OBS. LakeFormation LAKE_TABLE is not supported.
  • Currently, the supported Iceberg table version is V2 by default. V3 is not supported.

Procedure

This section uses real-time synchronization from RDS for MySQL to LakeFormation as an example to describe how to configure a real-time data migration job. Before that, ensure that you have read the instructions described in Performing a Check Before Using a Real-Time Job and completed all the preparations.

  1. Create a real-time migration job by following the instructions in Creating a Real-Time Migration Job and go to the job configuration page.
  2. Select the data connection type. Select MySQL for Source and Lakeformation for Destination.
  3. Select a job type. The default migration type is Real-time. The migration scenario is Entire DB.

    Figure 1 Selecting the migration job type

    For details about synchronization scenarios, see Synchronization Scenarios.

  4. Configure network resources. Select the created MySQL and LakeFormation data connections and the migration resource group for which the network connection has been configured.

    Figure 2 Selecting data connections and a migration resource group

    If no data connection is available, click Create to go to the Manage Data Connections page of the Management Center console and click Create Data Connection to create a connection. For details, see Configuring DataArts Studio Data Connection Parameters.

    If no migration resource group is available, click Create to create one. For details, see Buying a DataArts Migration Resource Group Incremental Package.

  5. Check the network connectivity. After the data connections and migration resource group are configured, perform the following operations to check the connectivity between the data sources and the migration resource group.

  6. Configure source parameters.

    Select the MySQL databases and tables to be migrated.
    Figure 3 Selecting databases and tables

    You can also click Import to import data from a file that you have edited based on the template. You can download the template as prompted on the console. Only a XLSX file no larger than 10 MB can be imported, and a maximum of 500 tables can be imported at a time. To ensure correct parsing, edit the file in strict accordance with the template format.

  7. Configure destination parameters.

    • Configure the mapping between the source database and table and the destination database and table.
      • Catalog: Select the required catalog.
      • Database Matching Policy
        • Same name as the source database: Data will be synchronized to the destination LakeFormation database with the same name as the source MySQL database.
        • Custom: Data will be synchronized to the destination LakeFormation table you specify.
      • Table Matching Policy
        • Same name as the source table: Data will be synchronized to the LakeFormation table with the same name as the source MySQL table.
        • Custom: Data will be synchronized to the LakeFormation table you specify.
          Figure 4 Configuring the mapping between the source database and table and the destination database and table

          When you customize a matching policy, you can use built-in variables #{source_db_name} and #{source_table_name} to identify the source database name and table name. The table matching policy must contain #{source_table_name}.

    • Configure the destination table.
      • Table Type: Select the required table type, for example, iceberg.
      • Store Format: Select the required table file format, for example, parquet.
      • Write Mode
        • copy-on-write
        • merge-on-read
      • Configure Table Attribute

        Custom table attributes: You can configure some advanced functions of the Iceberg table by setting parameters. To add table attributes, click Edit Table Attribute in the Operation column. For details about the table attributes supported by Iceberg, see the table attribute parameters on the official website.

  8. Refresh and check the mapping between the source and destination tables. In addition, you can modify table attributes, add additional fields, and use the automatic table creation capability to create tables in the destination LakeFormation database.

    Figure 5 Mapping between source and destination tables
    • Edit additional fields: Click Additional Field in the Operation column to add custom fields to the destination LakeFormation table. For a new table, you can add additional fields to the existing fields in the source table. You can customize the field name, select the field type, and enter the field value.
      • Field Name: name of the new field in the destination LakeFormation table
      • Field Type: type of the new field in the destination LakeFormation table
      • Field Value: value source of the new field in the destination LakeFormation table
        Table 5 Additional field value obtaining mode

        Type

        Example

        Constant

        Digits, letters, and special characters are supported. Color emoticons may cause a job submission failure.

        Built-in variable

        • Source host IP address: source.host
        • Source schema name: source.schema
        • Source table name: source.table
        • Destination schema name: target.schema
        • Destination table name: target.table

        Source table field

        Any field in the source table

        Do not change the name of the source table field when the job is running. Otherwise, the job may be abnormal.

        UDF

        • substring(#col, pos[, len]): obtains a substring of a specified length from the source column name. The substring range is [pos, pos+len).
        • date_format(#col, time_format[, src_tz, dst_tz]): formats the source column name based on a specified time format. The time zone can be converted using src_tz and dst_tz.
        • now([tz]): obtains the current time in a specified time zone.
        • if(cond_exp, str1, str2): returns str1 if the condition expression cond_exp is met and returns str2 otherwise.
        • concat(#col[, #str, ...]): concatenates multiple parameters, including source columns and strings.
        • from_unixtime(#col[, time_format]): formats a Unix timestamp based on a specified time format.
        • unix_timestamp(#col[, precision, time_format]): converts a time into a Unix timestamp of a specified time format and precision. time_format must be the same as that in the source data.
    • Edit table metadata: Click Edit Table Metadata in the Operation column to edit the metadata of a single table, mainly including the column information and attributes of the destination table. After editing the information, you can save the changes and create the table.
      Figure 6 Editing table metadata

      You can configure table partitions in the mapping configuration.

      Table 6 Table partition parameters that can be configured

      Transform Name

      Description

      Source Type

      Result Type

      identity

      Keeps the original value.

      geometry except for geography and variant

      Source type

      bucket[N]

      Hashes the value and takes the result modulo N.

      int,long,decimal,date,time,timestamp,timestamptz,timestamp_ns,timestamptz_ns,string,uuid,fixedbinary

      int

      truncate[W]

      Truncates the value to width W.

      int,long,decimal,string,binary

      Source type

      year

      Extracts the year from a date or timestamp, for example, a year starting from 1970

      date, timestamp, timestamptz, timestamp_ns, timestamptz_ns

      int

      month

      Extracts the month from a date or timestamp, for example, a month starting from 1970-01-01

      date, timestamp, timestamptz, timestamp_ns, timestamptz_ns

      int

      day

      Extracts a date or timestamp, for example, a date starting from 1970-01-01

      date, timestamp, timestamptz, timestamp_ns, timestamptz_ns

      int

      hour

      Extracts the hour from a timestamp, with 1970-01-01 00:00:00 as the basis.

      timestamp,timestamptz,timestamp_ns,timestamptz_ns

      int

      For details about Iceberg partitions, see the official website. You can configure table attributes. For details about the table attributes supported by Iceberg, see the official website.

    • Automatic table creation: Click Enable Auto Table Creation to automatically create tables in the destination database based on the configured mapping policy. After the tables are created, Existing table is displayed for them.
      Figure 7 Automatic Table Creation

      • DataArts Migration supports only automatic table creation. You need to manually create databases and schemas at the destination before using this function.
      • For details about the field type mapping for automatic table creation, see Field Type Mapping.

  9. Configure DDL message processing rules.

    Real-time migration jobs can synchronize data manipulation language (DML) operations, such as adding, deleting, and modifying data, as well as some table structure changes using the data definition language (DDL). You can set the processing policy for a DDL operation to Normal processing, Ignore, or Error.

    • Normal processing: When a DDL operation on the source database or table is detected, the operation is automatically synchronized to the destination.
    • Ignore: When a DDL operation on the source database or table is detected, the operation is ignored and not synchronized to the destination.
    • Error: When a DDL operation on the source database or table is detected, the migration job throws an exception.
      Figure 8 DDL configuration

  10. Configure task parameters.

    Table 7 Task parameters

    Parameter

    Description

    Default Value

    Execution Memory

    Memory allocated for job execution, which automatically changes with the number of CPU cores.

    8GB

    CPU Cores

    Value range: 2 to 32

    For each CPU core added, 4 GB execution memory and one concurrency are automatically added.

    2

    Concurrency

    Maximum number of jobs that can be concurrently executed. This parameter does not need to be configured and automatically changes with the number of CPU cores.

    1

    Auto Retry

    Whether to enable automatic retry upon a job failure

    No

    Maximum Retries

    This parameter is displayed when Auto Retry is set to Yes.

    1

    Retry Interval (Seconds)

    This parameter is displayed when Auto Retry is set to Yes.

    120

    Write Dirty Data

    Whether to record dirty data. By default, dirty data is not recorded. If there is a large amount of dirty data, the synchronization speed of the task is affected.

    • No: Dirty data is not recorded. This is the default value.

      Dirty data is not allowed. If dirty data is generated during the synchronization, the task fails and exits.

    • Yes: Dirty data is allowed, that is, dirty data does not affect task execution.
      When dirty data is allowed and its threshold is set:
      • If the generated dirty data is within the threshold, the synchronization task ignores the dirty data (that is, the dirty data is not written to the destination) and is executed normally.
      • If the generated dirty data exceeds the threshold, the synchronization task fails and exits.
        NOTE:

        Criteria for determining dirty data: Dirty data is meaningless to services, is in an invalid format, or is generated when the synchronization task encounters an error. If an exception occurs when a piece of data is written to the destination, this piece of data is dirty data. Therefore, data that fails to be written is classified as dirty data.

        For example, if data of the VARCHAR type at the source is written to a destination column of the INT type, dirty data cannot be written to the migration destination due to improper conversion. When configuring a synchronization task, you can configure whether to write dirty data during the synchronization and configure the number of dirty data records (maximum number of error records allowed in a single partition) to ensure task running. That is, when the number of dirty data records exceeds the threshold, the task fails and exits.

    No

    Dirty Data Policy

    This parameter is displayed when Write Dirty Data is set to Yes. The following policies are supported:

    • Do not archive: Dirty data is only recorded in job logs, but not stored.
    • Archive to OBS: Dirty data is stored in OBS and printed in job logs.

    Do not archive

    Write Dirty Data Link

    This parameter is displayed when Dirty Data Policy is set to Archive to OBS.

    Only links to OBS support dirty data writes.

    -

    Dirty Data Directory

    OBS directory to which dirty data will be written

    -

    Dirty Data Threshold

    This parameter is only displayed when Write Dirty Data is set to Yes.

    You can set the dirty data threshold as required.

    NOTE:
    • The dirty data threshold takes effect for each concurrency. For example, if the threshold is 100 and the concurrency is 3, the maximum number of dirty data records allowed by the job is 300.
    • Value -1 indicates that the number of dirty data records is not limited.

    100

    Add Custom Attribute

    You can add custom attributes to modify some job parameters and enable some advanced functions. For details, see Job Performance Optimization.

    -

  11. Submit and run the job.

    After configuring the job, click Submit in the upper left corner to submit the job.

    Figure 9 Submitting the job

    After submitting the job, click Start on the job development page. In the displayed dialog box, set required parameters and click OK.

    Figure 10 Starting the job

    Table 8 Parameters for starting the job

    Parameter

    Description

    Synchronization Mode

    • Incremental: Incremental data synchronization starts from a specified time point.
    • Full and incremental synchronization: All data is synchronized first, and then incremental data is synchronized in real time.
    • From the last save time: If the job has been started and saved, you can choose to synchronize data from the time when the job was last saved.

    Start Time

    This parameter must be set for incremental synchronization, and it specifies the start time of incremental synchronization.

    NOTE:

    If you set a time that is earlier than the earliest binlog time, the latest log time is used.

  12. Monitor the job.

    On the job development page, click Monitor to go to the Job Monitoring page. You can view the status and log of the job, and configure alarm rules for the job. For details, see Real-Time Migration Job O&M.

    Figure 11 Monitoring the job

Performance Optimization

If the synchronization speed is too slow, rectify the fault by referring to Job Performance Optimization.