Handle Failed DDL Statements in TiDB Data Migration

This document introduces how to handle failed DDL statements when you’re using the TiDB Data Migration (DM) tool to migrate data.

Currently, TiDB is not completely compatible with all MySQL syntax (see the DDL statements supported by TiDB). Therefore, when DM is migrating data from MySQL to TiDB and TiDB does not support the corresponding DDL statement, an error might occur and break the migration process. In this case, you can use the binlog command of DM to resume the migration.

Restrictions

Do not use this command in the following situations:

  • It is unacceptable in the actual production environment that the failed DDL statement is skipped in the downstream TiDB.
  • The failed DDL statement cannot be replaced with other DDL statements.
  • Other DDL statements must not be injected into the downstream TiDB.

For example, DROP PRIMARY KEY. In this scenario, you can only create a new table in the downstream with the new table schema (after executing the DDL statement), and re-import all the data into this new table.

Supported scenarios

During the migration, the DDL statement unsupported by TiDB is executed in the upstream and migrated to the downstream, and as a result, the migration task gets interrupted.

  • If it is acceptable that this DDL statement is skipped in the downstream TiDB, then you can use binlog skip <task-name> to skip migrating this DDL statement and resume the migration.
  • If it is acceptable that this DDL statement is replaced with other DDL statements, then you can use binlog replace <task-name> to replace this DDL statement and resume the migration.
  • If it is acceptable that other DDL statements are injected to the downstream TiDB, then you can use binlog inject <task-name> to inject other DDL statements and resume the migration.

Commands

When you use dmctl to manually handle the failed DDL statements, the commonly used commands include query-status and binlog.

query-status

The query-status command is used to query the current status of items such as the subtask and the relay unit in each MySQL instance. For details, see query status.

binlog

The binlog command is used to manage and show binlog operations. This command is only supported in DM v6.0 and later versions. For earlier versions, use the handle-error command.

The usage of binlog is as follows:

  1. binlog -h
  1. manage or show binlog operations
  3. Usage:
  4.   dmctl binlog [command]
  6. Available Commands:
  7.   inject      inject the current error event or a specific binlog position (binlog-pos) with some ddls
  8.   list        list error handle command at binlog position (binlog-pos) or after binlog position (binlog-pos)
  9.   replace     replace the current error event or a specific binlog position (binlog-pos) with some ddls
  10.   revert      revert the current binlog operation or a specific binlog position (binlog-pos) operation
  11.   skip        skip the current error event or a specific binlog position (binlog-pos) event
  13. Flags:
  14.   -b, --binlog-pos string   position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270"
  15.   -h, --help                help for binlog
  17. Global Flags:
  18.   -s, --source strings   MySQL Source ID.
  20. Use "dmctl binlog [command] --help" for more information about a command.

binlog supports the following sub-commands:

  • inject: injects DDL statements into the current error event or a specific binlog position. To specify the binlog position, refer to -b, --binlog-pos.
  • list: lists all valid inject, skip, and replace operations at the current binlog position or after the current binlog position. To specify the binlog position, refer to -b, --binlog-pos.
  • replace: replaces the DDL statement at a specific binlog position with another DDL statement. To specify the binlog position, refer to -b, --binlog-pos.
  • revert: reverts the inject, skip or replace operation at a specified binlog operation, only if the previous operation does not take effect. To specify the binlog position, refer to -b, --binlog-pos.
  • skip: skips the DDL statement at a specific binlog position. To specify the binlog position, refer to -b, --binlog-pos.

binlog supports the following flags:

  • -b, --binlog-pos:

    • Type: string.
    • Specifies a binlog position. When the position of the binlog event matches binlog-pos, the operation is executed. If it is not specified, DM automatically sets binlog-pos to the currently failed DDL statement.
    • Format: binlog-filename:binlog-pos, for example, mysql-bin|000001.000003:3270.
    • After the migration returns an error, the binlog position can be obtained from position in startLocation returned by query-status. Before the migration returns an error, the binlog position can be obtained by using SHOW BINLOG EVENTS in the upstream MySQL instance.

  • -s, --source:

    • Type: string.
    • Specifies the MySQL instance in which the preset operation is to be executed.

Usage examples

Skip DDL if the migration gets interrupted

If you need to skip the DDL statement when the migration gets interrupted, run the binlog skip command:

  1. binlog skip -h
  1. skip the current error event or a specific binlog position (binlog-pos) event
  3. Usage:
  4.   dmctl binlog skip <task-name> [flags]
  6. Flags:
  7.   -h, --help   help for skip
  9. Global Flags:
  10.   -b, --binlog-pos string   position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270"
  11.   -s, --source strings      MySQL Source ID.

Non-shard-merge scenario

Assume that you need to migrate the upstream table db1.tbl1 to the downstream TiDB. The initial table schema is:

  1. SHOW CREATE TABLE db1.tbl1;
  1. +-------+--------------------------------------------------+
  2. | Table | Create Table                                     |
  3. +-------+--------------------------------------------------+
  4. | tbl1  | CREATE TABLE `tbl1` (
  5.   `c1` int(11) NOT NULL,
  6.   `c2` decimal(11,3) DEFAULT NULL,
  7.   PRIMARY KEY (`c1`)
  8. ) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
  9. +-------+--------------------------------------------------+

Now, the following DDL statement is executed in the upstream to alter the table schema (namely, alter DECIMAL(11, 3) of c2 into DECIMAL(10, 3)):

  1. ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3);

Because this DDL statement is not supported by TiDB, the migration task of DM gets interrupted. Execute the query-status <task-name> command, and you can see the following error:

  1. ERROR 8200 (HY000): Unsupported modify column: can't change decimal column precision

Assume that it is acceptable in the actual production environment that this DDL statement is not executed in the downstream TiDB (namely, the original table schema is retained). Then you can use binlog skip <task-name> to skip this DDL statement to resume the migration. The procedures are as follows:

  1. Execute binlog skip <task-name> to skip the currently failed DDL statement:

    1. » binlog skip test
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         }
    11.     ]
    12. }

  2. Execute query-status <task-name> to view the task status:

    1. » query-status test

    See the execution result.

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "sourceStatus": {
    9.                 "source": "mysql-replica-01",
    10.                 "worker": "worker1",
    11.                 "result": null,
    12.                 "relayStatus": null
    13.             },
    14.             "subTaskStatus": [
    15.                 {
    16.                     "name": "test",
    17.                     "stage": "Running",
    18.                     "unit": "Sync",
    19.                     "result": null,
    20.                     "unresolvedDDLLockID": "",
    21.                     "sync": {
    22.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    23.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    24.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    25.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    26.                         "blockingDDLs": [
    27.                         ],
    28.                         "unresolvedGroups": [
    29.                         ],
    30.                         "synced": true,
    31.                         "binlogType": "remote",
    32.                         "totalRows": "4",
    33.                         "totalRps": "0",
    34.                         "recentRps": "0"
    35.                     }
    36.                 }
    37.             ]
    38.         }
    39.     ]
    40. }

    You can see that the task runs normally and the wrong DDL is skipped.

Shard merge scenario

Assume that you need to merge and migrate the following four tables in the upstream to one same table `shard_db`.`shard_table` in the downstream. The task mode is “pessimistic”.

  • MySQL instance 1 contains the shard_db_1 schema, which includes the shard_table_1 and shard_table_2 tables.
  • MySQL instance 2 contains the shard_db_2 schema, which includes the shard_table_1 and shard_table_2 tables.

The initial table schema is:

  1. SHOW CREATE TABLE shard_db.shard_table;
  1. +-------+-----------------------------------------------------------------------------------------------------------+
  2. | Table | Create Table                                                                                              |
  3. +-------+-----------------------------------------------------------------------------------------------------------+
  4. | tb    | CREATE TABLE `shard_table` (
  5.   `id` int(11) DEFAULT NULL,
  6.   PRIMARY KEY (`id`)
  7. ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
  8. +-------+-----------------------------------------------------------------------------------------------------------+

Now, execute the following DDL statement to all upstream sharded tables to alter their character set:

  1. ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DANISH_CI;

Because this DDL statement is not supported by TiDB, the migration task of DM gets interrupted. Execute the query-status command, and you can see the following errors reported by the shard_db_1.shard_table_1 table in MySQL instance 1 and the shard_db_2.shard_table_1 table in MySQL instance 2:

  1. {
  2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI",
  3.     "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8"
  4. }
  1. {
  2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_1` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI",
  3.     "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8"
  4. }

Assume that it is acceptable in the actual production environment that this DDL statement is not executed in the downstream TiDB (namely, the original table schema is retained). Then you can use binlog skip <task-name> to skip this DDL statement to resume the migration. The procedures are as follows:

  1. Execute binlog skip <task-name> to skip the currently failed DDL statements in MySQL instance 1 and 2:

    1. » binlog skip test
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         },
    11.         {
    12.             "result": true,
    13.             "msg": "",
    14.             "source": "mysql-replica-02",
    15.             "worker": "worker2"
    16.         }
    17.     ]
    18. }

  2. Execute the query-status command, and you can see the errors reported by the shard_db_1.shard_table_2 table in MySQL instance 1 and the shard_db_2.shard_table_2 table in MySQL instance 2:

    1. {
    2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI",
    3.     "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8"
    4. }
    1. {
    2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI",
    3.     "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8"
    4. }

  3. Execute binlog skip <task-name> again to skip the currently failed DDL statements in MySQL instance 1 and 2:

    1. » handle-error test skip
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         },
    11.         {
    12.             "result": true,
    13.             "msg": "",
    14.             "source": "mysql-replica-02",
    15.             "worker": "worker2"
    16.         }
    17.     ]
    18. }

  4. Use query-status <task-name> to view the task status:

    1. » query-status test

    See the execution result.

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "sourceStatus": {
    9.                 "source": "mysql-replica-01",
    10.                 "worker": "worker1",
    11.                 "result": null,
    12.                 "relayStatus": null
    13.             },
    14.             "subTaskStatus": [
    15.                 {
    16.                     "name": "test",
    17.                     "stage": "Running",
    18.                     "unit": "Sync",
    19.                     "result": null,
    20.                     "unresolvedDDLLockID": "",
    21.                     "sync": {
    22.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    23.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    24.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    25.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    26.                         "blockingDDLs": [
    27.                         ],
    28.                         "unresolvedGroups": [
    29.                         ],
    30.                         "synced": true,
    31.                         "binlogType": "remote",
    32.                         "totalRows": "4",
    33.                         "totalRps": "0",
    34.                         "recentRps": "0"
    35.                     }
    36.                 }
    37.             ]
    38.         },
    39.         {
    40.             "result": true,
    41.             "msg": "",
    42.             "sourceStatus": {
    43.                 "source": "mysql-replica-02",
    44.                 "worker": "worker2",
    45.                 "result": null,
    46.                 "relayStatus": null
    47.             },
    48.             "subTaskStatus": [
    49.                 {
    50.                     "name": "test",
    51.                     "stage": "Running",
    52.                     "unit": "Sync",
    53.                     "result": null,
    54.                     "unresolvedDDLLockID": "",
    55.                     "sync": {
    56.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    57.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    58.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    59.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    60.                         "blockingDDLs": [
    61.                         ],
    62.                         "unresolvedGroups": [
    63.                         ],
    64.                         "synced": true,
    65.                         "binlogType": "remote",
    66.                         "totalRows": "4",
    67.                         "totalRps": "0",
    68.                         "recentRps": "0"
    69.                     }
    70.                 }
    71.             ]
    72.         }
    73.     ]
    74. }

    You can see that the task runs normally with no error and all four wrong DDL statements are skipped.

Replace DDL if the migration gets interrupted

If you need to replace the DDL statement when the migration gets interrupted, run the binlog replace command:

  1. binlog replace -h
  1. replace the current error event or a specific binlog position (binlog-pos) with some ddls
  3. Usage:
  4.   dmctl binlog replace <task-name> <replace-sql1> <replace-sql2>... [flags]
  6. Flags:
  7.   -h, --help   help for replace
  9. Global Flags:
  10.   -b, --binlog-pos string   position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270"
  11.   -s, --source strings      MySQL Source ID.

Non-shard-merge scenario

Assume that you need to migrate the upstream table db1.tbl1 to the downstream TiDB. The initial table schema is:

  1. SHOW CREATE TABLE db1.tbl1;
  1. +-------+-----------------------------------------------------------------------------------------------------------+
  2. | Table | Create Table                                                                                              |
  3. +-------+-----------------------------------------------------------------------------------------------------------+
  4. | tb    | CREATE TABLE `tbl1` (
  5.   `id` int(11) DEFAULT NULL,
  6.   PRIMARY KEY (`id`)
  7. ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
  8. +-------+-----------------------------------------------------------------------------------------------------------+

Now, perform the following DDL operation in the upstream to add a new column with the UNIQUE constraint:

  1. ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE;

Because this DDL statement is not supported by TiDB, the migration task gets interrupted. Execute the query-status command, and you can see the following error:

  1. {
  2.     "Message": "cannot track DDL: ALTER TABLE `db1`.`tbl1` ADD COLUMN `new_col` INT UNIQUE KEY",
  3.     "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'db1.tbl1'",
  4. }

You can replace this DDL statement with two equivalent DDL statements. The steps are as follows:

  1. Replace the wrong DDL statement by the following command:

    1. » binlog replace test "ALTER TABLE `db1`.`tbl1` ADD COLUMN `new_col` INT;ALTER TABLE `db1`.`tbl1` ADD UNIQUE(`new_col`)";
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         }
    11.     ]
    12. }

  2. Use query-status <task-name> to view the task status:

    1. » query-status test

    See the execution result.

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "sourceStatus": {
    9.                 "source": "mysql-replica-01",
    10.                 "worker": "worker1",
    11.                 "result": null,
    12.                 "relayStatus": null
    13.             },
    14.             "subTaskStatus": [
    15.                 {
    16.                     "name": "test",
    17.                     "stage": "Running",
    18.                     "unit": "Sync",
    19.                     "result": null,
    20.                     "unresolvedDDLLockID": "",
    21.                     "sync": {
    22.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    23.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    24.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    25.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    26.                         "blockingDDLs": [
    27.                         ],
    28.                         "unresolvedGroups": [
    29.                         ],
    30.                         "synced": true,
    31.                         "binlogType": "remote",
    32.                         "totalRows": "4",
    33.                         "totalRps": "0",
    34.                         "recentRps": "0"
    35.                     }
    36.                 }
    37.             ]
    38.         }
    39.     ]
    40. }

    You can see that the task runs normally and the wrong DDL statement is replaced by new DDL statements that execute successfully.

Shard merge scenario

Assume that you need to merge and migrate the following four tables in the upstream to one same table `shard_db`.`shard_table` in the downstream. The task mode is “pessimistic”.

  • In the MySQL instance 1, there is a schema shard_db_1, which has two tables shard_table_1 and shard_table_2.
  • In the MySQL instance 2, there is a schema shard_db_2, which has two tables shard_table_1 and shard_table_2.

The initial table schema is:

  1. SHOW CREATE TABLE shard_db.shard_table;
  1. +-------+-----------------------------------------------------------------------------------------------------------+
  2. | Table | Create Table                                                                                              |
  3. +-------+-----------------------------------------------------------------------------------------------------------+
  4. | tb    | CREATE TABLE `shard_table` (
  5.   `id` int(11) DEFAULT NULL,
  6.   PRIMARY KEY (`id`)
  7. ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
  8. +-------+-----------------------------------------------------------------------------------------------------------+

Now, perform the following DDL operation to all upstream sharded tables to add a new column with the UNIQUE constraint:

  1. ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE;

Because this DDL statement is not supported by TiDB, the migration task gets interrupted. Execute the query-status command, and you can see the following errors reported by the shard_db_1.shard_table_1 table in MySQL instance 1 and the shard_db_2.shard_table_1 table in MySQL instance 2:

  1. {
  2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` ADD COLUMN `new_col` INT UNIQUE KEY",
  3.     "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'shard_db_1.shard_table_1'",
  4. }
  1. {
  2.     "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_1` ADD COLUMN `new_col` INT UNIQUE KEY",
  3.     "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'shard_db_2.shard_table_1'",
  4. }

You can replace this DDL statement with two equivalent DDL statements. The steps are as follows:

  1. Replace the wrong DDL statements respectively in MySQL instance 1 and MySQL instance 2 by the following commands:

    1. » binlog replace test -s mysql-replica-01 "ALTER TABLE `shard_db_1`.`shard_table_1` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_1`.`shard_table_1` ADD UNIQUE(`new_col`)";
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         }
    11.     ]
    12. }
    1. » binlog replace test -s mysql-replica-02 "ALTER TABLE `shard_db_2`.`shard_table_1` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_2`.`shard_table_1` ADD UNIQUE(`new_col`)";
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-02",
    9.             "worker": "worker2"
    10.         }
    11.     ]
    12. }

  2. Use query-status <task-name> to view the task status, and you can see the following errors reported by the shard_db_1.shard_table_2 table in MySQL instance 1 and the shard_db_2.shard_table_2 table in MySQL instance 2:

    1. {
    2.     "Message": "detect inconsistent DDL sequence from source ... ddls: [ALTER TABLE `shard_db`.`tb` ADD COLUMN `new_col` INT UNIQUE KEY] source: `shard_db_1`.`shard_table_2`], right DDL sequence should be ..."
    3. }
    1. {
    2.     "Message": "detect inconsistent DDL sequence from source ... ddls: [ALTER TABLE `shard_db`.`tb` ADD COLUMN `new_col` INT UNIQUE KEY] source: `shard_db_2`.`shard_table_2`], right DDL sequence should be ..."
    3. }

  3. Execute handle-error <task-name> replace again to replace the wrong DDL statements in MySQL instance 1 and 2:

    1. » binlog replace test -s mysql-replica-01 "ALTER TABLE `shard_db_1`.`shard_table_2` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_1`.`shard_table_2` ADD UNIQUE(`new_col`)";
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-01",
    9.             "worker": "worker1"
    10.         }
    11.     ]
    12. }
    1. » binlog replace test -s mysql-replica-02 "ALTER TABLE `shard_db_2`.`shard_table_2` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_2`.`shard_table_2` ADD UNIQUE(`new_col`)";
    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "mysql-replica-02",
    9.             "worker": "worker2"
    10.         }
    11.     ]
    12. }

  4. Use query-status <task-name> to view the task status:

    1. » query-status test

    See the execution result.

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "sourceStatus": {
    9.                 "source": "mysql-replica-01",
    10.                 "worker": "worker1",
    11.                 "result": null,
    12.                 "relayStatus": null
    13.             },
    14.             "subTaskStatus": [
    15.                 {
    16.                     "name": "test",
    17.                     "stage": "Running",
    18.                     "unit": "Sync",
    19.                     "result": null,
    20.                     "unresolvedDDLLockID": "",
    21.                     "sync": {
    22.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    23.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    24.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    25.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    26.                         "blockingDDLs": [
    27.                         ],
    28.                         "unresolvedGroups": [
    29.                         ],
    30.                         "unresolvedGroups": [
    31.                         ],
    32.                         "synced": true,
    33.                         "binlogType": "remote",
    34.                         "totalRows": "4",
    35.                         "totalRps": "0",
    36.                         "recentRps": "0"
    37.                     }
    38.                 }
    39.             ]
    40.         },
    41.         {
    42.             "result": true,
    43.             "msg": "",
    44.             "sourceStatus": {
    45.                 "source": "mysql-replica-02",
    46.                 "worker": "worker2",
    47.                 "result": null,
    48.                 "relayStatus": null
    49.             },
    50.             "subTaskStatus": [
    51.                 {
    52.                     "name": "test",
    53.                     "stage": "Running",
    54.                     "unit": "Sync",
    55.                     "result": null,
    56.                     "unresolvedDDLLockID": "",
    57.                     "sync": {
    58.                         "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    59.                         "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10",
    60.                         "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)",
    61.                         "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4",
    62.                         "blockingDDLs": [
    63.                         ],
    64.                         "unresolvedGroups": [
    65.                         ],
    66.                         "unresolvedGroups": [
    67.                         ],
    68.                         "synced": try,
    69.                         "binlogType": "remote",
    70.                         "totalRows": "4",
    71.                         "totalRps": "0",
    72.                         "recentRps": "0"
    73.                     }
    74.                 }
    75.             ]
    76.         }
    77.     ]
    78. }

    You can see that the task runs normally with no error and all four wrong DDL statements are replaced.

Other commands

For the usage of other commands of binlog, refer to the binlog skip and binlog replace examples above.