dm同步时候的bug

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
v5.0.1
dm版本：v2.0.3
【问题描述】
操作步骤：
建表：
CREATE TABLE dm_test1 (
id int(10) NOT NULL,
a varchar(20) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

插入数据：
insert into dm_test1 values(1,‘123’);

到此时DM同步是正常的，接下来我们执行如下操作
CREATE TABLE if exists dm_test1 (
id int(10) NOT NULL primary key);

然后执行更改数据：
update dm_test1 set a=“asfas” where id=1;

接下来查看同步状态，则会报错：
startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.000002, 13783), gtid-set: ]: gen update sqls failed, schema: dm_test1, table: dm_test1: Column count doesn’t match value count: 1 (columns) vs 2 (values)"

这绝不是因为rds的虚拟主键，可以把初始建表改成4个字段，则会出现1vs4的报错,我想是对if not exists这块处理有问题

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

1 个赞
2

这句指的是 CREATE TABLE if not exists dm_test1?

使用 MySQL 没有复现这个问题，需要您提供上游版本号，任务配置文件，以及 DM worker 日志

3

对，是if not exists,上游是mysql5.7.30,阿里云的rds,自建的mysql,有无gtid都试过,查query-status，错误信息里有，错误信息有，我两套环境都试过，同样的问题

配置文件

任务名，多个同时运行的任务不能重名。

name: “dm-test_8363”

全量+增量 (all) 迁移模式。

task-mode: “all”

下游 TiDB 配置信息。

target-database:

当前数据迁移任务需要的全部上游 MySQL 实例配置。

mysql-instances:

上游实例或者复制组 ID，参考 inventory.ini 的 source_id 或者 dm-master.toml 的 source-id 配置。

source-id: “mysql-replica-01”

需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 block-allow-list 的配置。

block-allow-list: “global” # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。

dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。

mydumper-config-name: “global”

#-

source-id: “mysql-replica-02”

block-allow-list: “global” # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。

mydumper-config-name: “global”

黑白名单全局配置，各实例通过配置项名引用。

block-allow-list: # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
global:
do-dbs: [“dm_test1”]
do-tables: # 需要迁移的上游表的白名单。
- db-name: “dm_test1” # 需要迁移的表的库名。
tbl-name: “dm_test1” # 需要迁移的表的名称。
- db-name: “dm_test1”
tbl-name: “dm_test2”

dump 处理单元全局配置，各实例通过配置项名引用。

mydumpers:
global:
extra-args: “-B dm_test1” # dump 处理单元的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。

这个环境此前一直正常运行，是因为另一个环境有错误，我把该语句拿到这里测试

重点：create table if not exists的字段数一定要和原表不一致

日志里没有什么有用的信息

4

感谢反馈

5

客气了

6

有进展你会收到邮件提醒哈，另外会在帖子回复。

7

好的，辛苦了

8

我们这边按照一楼的步骤和三楼的配置文件，没有办法复现出问题。您那边方便复现的话，可以把 DM-worker 日志等级修改为 debug 级别，复现一下提交日志吗

如果您是 binary 部署的，可以按照如下形式启动一个 1 master 1 worker 的集群用于复现。TiUP 部署的话，也可以找到相应的 binary

bin/dm-master --master-addr='127.0.0.1:<master-port>' --log-file='/tmp/dm-master.log' -L=debug
bin/dm-worker --worker-addr='127.0.0.1:<worker-port>' --log-file='/tmp/dm-worker.log' -L=debug --join='127.0.0.1:<master-port>'

<master-port> 跟 <worker-port> 可以选择本机任意的没有被占用的端口

bin/dmctl --master-addr=127.0.0.1:<master-port>

dmctl 按照如上方式进行连接

9

请问您这最后有执行update语句么，我两个环境都报错了，我觉得不应该是个例啊

10

第一个create table 在dm开启之前创建

11

噢噢，我第一个语句并不是在dm开启前的。之后尝试一下，感谢

12

复现成功，感谢反馈。您可以在 https://github.com/pingcap/dm/issues/1697 查看修复进度

13

好的好的，辛苦了:+1::+1::+1:

14

:+1::+1::+1:

15

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。