All Products
Search
Document Center

DataWorks:Real-time MySQL to Elasticsearch synchronization

Last Updated:Jun 21, 2026

Data Integration supports the real-time synchronization of an entire database from a source, such as MySQL, to Elasticsearch. This topic uses a MySQL-to-Elasticsearch scenario to describe how to perform full and incremental real-time synchronization.

Prerequisites

Configure the task

Step 1: Create a synchronization task

  1. Log on to the DataWorks console. In the target region, click Data Integration > Data Integration in the left-side navigation pane. Select a workspace from the drop-down list and click Go to Data Integration.

  2. In the left-side navigation pane, click Synchronization Task. On the page that appears, click Create Synchronization Task and configure the task information.

    • Source Type: MySQL.

    • Destination Type: Elasticsearch.

    • Specific Type: real-time synchronization of entire database.

    • Synchronization Mode:

      • Schema Migration: Automatically creates a matching index structure, such as indexes and field mappings, in the destination. This step does not migrate data.

      • Full Synchronization (Optional): Copies all historical data from specified source objects, such as tables, to the destination at once. This is typically used for initial data migration or initialization.

      • Incremental Sync (Optional): After the full synchronization is complete, continuously captures data changes (inserts, updates, and deletes) from the source and synchronizes them to the destination.

Step 2: Configure data sources and computing resources

  1. For Source, select the MySQL data source. For Destination, select the Elasticsearch data source.

  2. In the Running Resources section, select the Resource Group for the synchronization task, and allocate Resource Group CU to the task.

    Note

    If the task logs display a message such as Please confirm whether there are enough resources..., it indicates that the available compute units (CUs) in the current resource group are insufficient for starting or running the task. You can increase the number of CUs allocated to the task in the Configure Resource Group panel to allocate more compute resources.

    For recommended resource size values, see Recommended CUs for Data Integration. Adjust the values based on your actual requirements.

  3. Ensure that both the source data source and the destination data source pass the Connectivity Check.

Step 3: Configure the synchronization plan

1. Configure the data source

  • In this step, you can select the tables to synchronize from the source data source in the Source Tables section, and click the image icon to move them to the Selected Tables section on the right. If there are many tables, you can use Database Filtering or Table filtering to select the tables to synchronize by configuring regular expressions.

    image

  • To write data from multiple sharded tables (with the same schema) to a single destination table, you can Select Tables by Regex.

    image
    Enter a regular expression in the source table configuration. DataWorks automatically identifies and collects all matching source tables and writes their data to the destination table mapped by the expression.

    Note

    This method is applicable to sharded table merge synchronization scenarios (similar to sharding-based synchronization), improving configuration efficiency and avoiding the need to repeatedly add many-to-one synchronization rules.

2. Configure destination index mapping

Actions

Description

Refresh

The system automatically lists the source tables that you selected. However, the properties of the destination index apply only after you refresh and confirm them.

  • Select multiple tables to synchronize and click Batch Refresh Mapping Results.

  • Destination index name: The destination index name is automatically generated based on the Customize Mapping Rules for Destination Table Names rule. The default name is ${source_database_name}_${table_name}. If an index with this name does not exist in the destination, the system automatically creates it.

Custom Mapping Rule for Destination Index Name (Optional)

The system uses a default rule to generate index names: ${source_database_name}_${table_name}. You can also click the Edit button in the Customize Mapping Rules for Destination Table Names column to add a custom rule.

  • Rule name: Define a name for the rule. We recommend that you specify a name that is descriptive and reflects its business purpose.

  • Destination index name: You can construct the destination index name by clicking the image button and combining values from Manual Input and Built-in Variable. The supported variables include the source data source name, source database name, and source table name.

  • Edit built-in variables: You can apply string transformations to the built-in variables.

This feature supports the following scenarios:

  1. Add prefixes or suffixes to names: Add a prefix or suffix to the source table name by setting a constant.

    Rule configuration

    Result

    In the Rule name field, enter pre_table_post. The Destination index name is composed of three parts: the text pre_, the source table name built-in variable, and the text _post.

    After you apply the pre_table_post rule, the source table userinfo is mapped to the destination index pre_userinfo_post (to be created), and the source table userinfo1 is mapped to the destination index pre_userinfo1_post (to be created).

  2. Perform global string replacement: Replace the string dev_ in all source table names with prd_.

    Rule configuration

    Result

    In the Destination index name drop-down list, select the Source table name built-in variable and go to the Edit built-in variables page. On the Source table name tab, configure a string replacement rule to replace the source string dev_ with the destination string prd_. Rules are executed from top to bottom. You can use Move Up, Move Down, and Delete to adjust the order of rules or remove them.

    The result shows that the source tables dev_table1 and dev_table2 are mapped to the destination indexes prd_table1 and prd_table2 (to be created) by using the replace rule. The dev_ prefix is replaced with prd_.

  3. Write data from multiple tables to a single table: Set the destination index name to a constant value.

    Rule configuration

    Result

    In the Destination index name field, enter a fixed value such as my_table to map all source tables to the same destination table.

    Result: The source tables table_01 and table_02 from the source database mysql_test2 are both mapped to the same destination index my_table (to be created). This allows you to merge data from multiple tables into a single index.

Edit Field Type Mapping (Optional)

The system provides a default mapping between the Source Type and Destination Type. You can click Edit Mapping of Field Data Types in the upper-right corner of the table to customize the mapping of field data types between the source tables and destination indexes. After you complete the configuration, click Apply and Refresh Mapping.

When you edit field type mappings, make sure that the type conversion rules are valid. Otherwise, type conversion failures can occur, generating dirty data and disrupting the task.

Edit Destination Index (Optional)

Based on the custom index name mapping rules, the system automatically creates new destination indexes or reuses existing ones with matching names.

DataWorks automatically generates the destination index structure based on the source table structure. In most cases, manual intervention is not required.

When the destination index status is To be created, you can add new fields to the destination index based on its original table structure. Perform the following operations:

  1. Add fields to the destination index.

    • Add fields to a single index: Click the image.png icon in the Destination Index Name column and add fields by editing the Statement Used to Create Index.

      • Dynamic Mapping Status: Specifies whether to add new fields from the source table to the destination index during data synchronization. Valid values:

        • true: If the system detects new fields in the source table, it adds the fields to the destination index. These fields can then be searched. This is the default value.

        • false: If the system detects new fields in the source table, it adds the fields to the destination index, but these fields are not searchable.

        • strict: If the system detects new fields in the source table, it refuses to add the fields to the destination index and throws an exception. You can view the error details in the logs.

        • runtime: If the system detects new fields in the source table, the new fields are not added to the index mapping. Instead, they are treated as runtime fields at query time. This allows the fields to be used in script calculations and searches.

        For more information about dynamic mapping, see Dynamic mapping.

      • Shards and Replica Shards: The number of primary and replica shards for an index. A complete index is divided into multiple shards and distributed across different Elasticsearch nodes to enable distributed search and improve query performance. For more information, see Basic concepts.

        Note

        The values of the Shards and Replica Shards parameters cannot be changed after the task runs. The default value for both parameters is 1.

    • Batch add fields: Select all tables to be synchronized, and at the bottom of the table, select Batch Modify > Destination Index Structure - Batch Add Fields.

Value assignment

Native fields are automatically mapped based on matching field names between the source and destination. You must manually assign values for the new fields and destination index properties you added. Perform the following operations:

  • Assign values for a single table: Click the Configuration button in the Value assignment column to assign values to the destination index fields.

  • Assign values in a batch: At the bottom of the list, select Batch Modify > Value assignment to assign values to identical fields across multiple destination indexes at the same time.

You can assign constants and variables by changing the Value Type. The following options are supported:

  • Destination index field:

    • Manual assignment: Enter a constant value, such as abc.

    • Source field: Assigns a value from a source table field. You can select either the field value or a time value.

      • Field value: Writes the value of the source field directly to the destination.

      • Time value: If the source field contains a time value, you can process it by using different formats and specify a Destination Format to format the extracted value.

        • Time string: A string that represents a time or date, such as "2018-10-23 02:13:56" or "2021/05/18". The string is parsed into a date or time value by specifying a time format. For example, the strings in the preceding examples can be recognized by using the yyyy-MM-dd HH:mm:ss and yyyy/MM/dd formats.

        • Time object: If the source value is of a time data type such as Date or Datetime, you can directly select this type.

        • Unix timestamp (seconds): A 10-digit timestamp in seconds, which can be provided as a number or string. Examples: 1610529203 and "1610529203".

        • Unix timestamp (milliseconds): A 13-digit timestamp in milliseconds, which can be provided as a number or string. Examples: 1610529203002 and "1610529203002".

    • Select variable: Select a system-provided variable as the value source.

    • Function: Use functions to apply simple transformations to the source field before you assign it as the value. For more information, see Use function expressions to assign values to destination table fields.

  • Destination index property assignment: Assign a value to the primary key for the destination index. You can concatenate multiple source fields to create a composite primary key. Make sure that the resulting value is unique.

Source split column

You can select a field from the source table in the Source split column drop-down list or select Not Split. When the synchronization task runs, it is split into multiple subtasks based on this column to read data in batches and in parallel.

We recommend that you use the primary key of the table as the source split column. String, float, and date types are not supported.

The source split column is supported only when the source is MySQL.

Skip full synchronization

If you have configured full synchronization in Step 3, you can choose to skip full synchronization for individual tables. This is useful if you have already synchronized the full data to the destination by using other methods.

Full condition

Applies a filter to the source data during the full synchronization phase. Enter only the filter conditions of a WHERE clause. Do not include the WHERE keyword.

Configure DML Rule

DML message processing applies fine-grained filtering and control to the change data (Insert, Update, and Delete) that is captured from the source before the data is written to the destination. This rule applies only during the incremental sync phase.

Step 4: Advanced settings

Advanced parameter configuration

To customize the task, modify the parameters on the Advanced Parameters tab.

  1. Click Advanced Settings in the upper-right corner to go to the advanced parameter configuration page.

  2. Modify the parameter values based on the descriptions provided.

  3. You can also use AI-powered configuration. Input a command in natural language, such as a command to adjust the task concurrency, and the AI model generates recommended parameter values. You can choose whether to accept the AI-generated parameters.

    In addition to accepting or rejecting the suggestions, you can click Regenerate to have Copilot provide new parameter recommendations.

Important

Modify these parameters only if you fully understand their purpose. This helps prevent unexpected issues such as task latency, excessive resource consumption that blocks other tasks, and data loss.

DDL capability configuration

Some real-time synchronization channels can detect metadata changes in the source table schema and notify the destination to synchronize the updates, or take other actions such as alerting, ignoring, or terminating the task.

You can click Configure DDL Capability in the upper-right corner to set the processing policy for each type of change. The supported processing policies vary by channel.

  • Normal processing: The destination processes the DDL change information from the source.

  • Ignore: The change message is ignored, and the destination is not modified.

  • Error: The real-time full-database synchronization task is terminated, and the status is set to Error.

  • Alert: An alert is sent to you when this type of change occurs on the source. You must configure a DDL notification rule in Configure Alert Rule.

Note

After a new column is added on the source and created on the destination through DDL synchronization, the system does not backfill data for the existing data in the destination table.

Step 5: Deploy and run the task

  1. After you complete all configurations, click Save at the bottom of the page to save the task configuration.

  2. Full-database synchronization tasks do not support direct debugging. You must deploy them to Operation Center for execution. Therefore, you must perform the Deploy operation to make any new or edited task take effect.

  3. During deployment, if you select Start immediately after deployment, the task starts simultaneously with the deployment. Otherwise, after deployment, you must go to Data Integration > Synchronization Task and manually start the task in the Operation column of the target task.

  4. Click the Name/ID of the corresponding task in Tasks to view the detailed execution process of the task.

Step 6: Alert configuration

1. Create an alert

In the Data Integration > Synchronization Task list, find the real-time full-database task, and click More > Alerts in the Operation column to configure alert policies for the task.

image

(1) Click Create Rule to configure an alert rule.

You can set Alert Reason to monitor task metrics such as Business delay, Failover, Task status, DDL Notification, and Task Resource Utilization, and set CRITICAL or WARNING alert levels based on specified thresholds.

  • By configuring Configure Advanced Parameters, you can control the time interval between alert messages to prevent sending too many messages at once, which can cause waste and message accumulation.

  • If the alert reason is set to Business delay, Task status, or Task Resource Utilization, you can also enable recovery notifications to notify recipients when the task returns to normal.

(2) Manage alert rules.

For existing alert rules, you can use the alert switch to enable or disable alert rules. You can also send alerts to different people based on the alert level.

2. View alerts

Click More > Configure Alert Rule in the task list to expand the panel and go to the alert events page, where you can view alerts that have occurred.

Manage task

Edit task

  1. On the Data Integration > Synchronization Task page, find the synchronization task that you created. In the Operation column, choose More > Edit to modify the task information. The steps are the same as those for configuring a new task.

  2. For tasks that are not running, you can directly modify and save the configuration and then deploy the task to Operation Center to apply the changes.

  3. For tasks that are Running, if you edit and deploy the task without selecting Start immediately after deployment, the original action button changes to Apply Updates. You must click this button for the changes to take effect in Operation Center.

  4. After you click Apply Updates, the system stops, deploys, and restarts the task to apply the changes.

    • If you add new tables or switch existing tables:

      You cannot select a position when you apply the update. After you confirm the update, the system performs schema migration and full synchronization for the new tables. After the initialization is complete, incremental sync starts for these tables along with the original ones.

    • If you modify other information:

      You can select a position when you apply updates. After you confirm, the task resumes from the specified position. If you do not specify a position, it resumes from the position at which it last stopped (the last checkpoint).

    Unmodified tables are not affected. After the update and restart, they resume from the last checkpoint.

View task

After you create a synchronization task, you can view the list of created tasks and their basic information on the Synchronization Task page.

  • In the Operation column, you can Start or Stop a synchronization task. In the More menu, you can perform other operations such as Edit and View.

  • For running tasks, you can view their status in the Execution Overview section. You can also click a specific area of the overview to view execution details. Click View to go to the synchronization task details page. The Basic Information section at the top displays the task ID, data sources (for example, MySQL_Source → Elasticsearch_Source), creation time, synchronization resource group, status (Running), synchronization plan (real-time synchronization of entire database), and the CUs the task occupies. The Execution Status section in the middle uses progress bars to show the completion percentage and running status of the three stages: schema migration, full synchronization, and real-time data synchronization.

    A real-time synchronization task from MySQL to Elasticsearch consists of three stages:

    • Schema migration: Shows how the destination index was created (from an existing index or automatically created). If the index was automatically created, the DDL statement is displayed.

    • Full synchronization: Displays information about the tables synchronized by using offline synchronization, their progress, and the number of records written.

    • Real-time data synchronization: Displays real-time statistics, including progress, DDL and DML records, and alert information.

Rerun a task

In certain scenarios, such as when you need to add or remove tables, or modify destination table schema or table name information, you can click Rerun in the Operations column of the synchronization task. The system synchronizes only the newly added or modified tables. Previously synchronized or unmodified tables are not synchronized again.

  • Click Rerun to rerun the full initialization and real-time synchronization.

  • Edit the task to add or remove tables, save the task, and then deploy it. After the deployment, the Apply Updates button appears in the Operations column. Click Apply Updates to trigger a rerun of the modified task. Only the newly added or modified tables are synchronized. Previously synchronized tables are not synchronized again.

Resume from checkpoint

Use cases

Resetting the task's starting position is useful for the following scenarios:

  • Task recovery and data resumption: If a task is interrupted, manually specify the interruption time as the new starting position to resume data synchronization from the correct point.

  • Data troubleshooting and rollback: If you find missing or abnormal data after synchronization, roll back the position to a time before the issue occurred to replay and correct the data.

  • Major task configuration changes: After you make significant adjustments to the task configuration, such as the destination index structure or field mappings, reset the position to start synchronization from a specific point. This ensures data accuracy under the new configuration.

Procedure

Click Start. In the dialog box that appears, select whether to Whether to reset the site.

  • If you do not select the check box, the task resumes from the last stopping point (the last checkpoint).

  • If you select the check box and specify a time, the task starts from the specified time. Make sure that the selected time is not earlier than the earliest available position in the source Binlog.

Important

If you encounter an error about an invalid or non-existent position, use the following solutions:

  • Reset the position: When you start the real-time synchronization task, reset the position and select the earliest available position in the source database.

  • Adjust the log retention period: If the database position has expired, increase the log retention period in the database, for example, to 7 days.

  • Resynchronize data: If data has been lost, perform a full synchronization again or configure an offline synchronization task to manually synchronize the missing data.

FAQ

For frequently asked questions about real-time database synchronization, see Data Integration FAQ and Data Integration errors.