handle-error After handling the error, the next DML is lost

[jacktd9]

What did you do?

• 上游数据库：10.0.11-MariaDB
• DM 版本：v5.3.1
• DM 同步策略：乐观模式、分库合表

# source A 、 B  的 r1 表
CREATE TABLE `r1` (
  `id` int(11) NOT NULL COMMENT '',
  `a` DECIMAL(20,6) DEFAULT '0.000000' COMMENT '',
  `b` varchar(32) DEFAULT NULL COMMENT '',
  `d` double(4,2) NOT NULL COMMENT '',
  `first_apply_proof_time` datetime DEFAULT NULL COMMENT '首次申请时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

# source A
insert into r1 values(1, 1.111111, '111', 11.11,now());

# source B
insert into r1 values(2, 2.222222, '222', 22.22,now());

# source A - 字段精度变小
ALTER TABLE `r1` MODIFY COLUMN `a` DECIMAL(20,2) DEFAULT NULL COMMENT '';

# source A 
insert into r1 values(3, 3.333333, '333', 33.33,now());
insert into r1 values(4, 4.444444, '444', 44.44,now());

# dm handle-error mcfcm_q skip

# 下游丢失一条 “3, 3.333333, '333', 33.33,now()” 数据

What did you expect to see?

MySQL [mcfcmadm_v531]> select * from r1;
+----+----------+------+-------+------------------------+
| id | a        | b    | d     | first_apply_proof_time |
+----+----------+------+-------+------------------------+
|  1 | 1.111111 | 111  | 11.11 | 2023-03-02 17:41:05    |
|  2 | 2.222222 | 222  | 22.22 | 2023-03-02 17:41:10    |
|  3 | 3.333333 | 333  | 33.33 | 2023-03-02 17:41:23    |
|  4 | 4.444444 | 444  | 44.44 | 2023-03-02 17:41:23    |
+----+----------+------+-------+------------------------+
4 rows in set (0.00 sec)

What did you see instead?

MySQL [mcfcmadm_v531]> select * from r1;
+----+----------+------+-------+------------------------+
| id | a        | b    | d     | first_apply_proof_time |
+----+----------+------+-------+------------------------+
|  1 | 1.111111 | 111  | 11.11 | 2023-03-02 17:41:05    |
|  2 | 2.222222 | 222  | 22.22 | 2023-03-02 17:41:10    |
|  4 | 4.444444 | 444  | 44.44 | 2023-03-02 17:41:23    |
+----+----------+------+-------+------------------------+
3 rows in set (0.00 sec)

Versions of the cluster

DM version (run dmctl -V or dm-worker -V or dm-master -V):

Release Version: v5.3.1
Git Commit Hash: 630896740566eb0f7a81062506e92177e755f404
Git Branch: heads/refs/tags/v5.3.1
UTC Build Time: 2022-03-03 10:19:44
Go Version: go version go1.16.4 linux/amd64

Upstream MySQL/MariaDB server version:

10.0.11-MariaDB-log 

| Release Version: v4.0.12-2-g72d7d3c94 Edition: Community Git Commit Hash: 72d7d3c9413fe4009963121e4eeaae8a3f095648 Git Branch: HEAD UTC Build Time: 2021-07-08 06:57:48 GoVersion: go1.13.15 Race Enabled: false TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 Check Table Before Drop: false

How did you deploy DM: tiup or manually?

TiUP

Other interesting information (system version, hardware config, etc):

>
>

current status of DM cluster (execute query-status <task-name> in dmctl)

(paste current status of DM cluster here)

[fubinzh]

/severity Critical

[niubell]

It affects v5.3 and v5.4, we have fixed this issue in this https://github.com/pingcap/tiflow/issues/5394 corresponding development, you can use 6.1 or higher versions to avoid it.

[fubinzh]

/remove-severity critical

[fubinzh]

/severity moderate