DM同步任务报错 Column xxx cannot be null

[TiDB 版本]
v4.0.8

[DM版本]
v1.3.1

[问题描述]
用 dm 同步上游数据库到 mysql 的时候,遇到这个报错始终无法跳过,如下:
“errors”: [
{
“ErrCode”: 10006,
“ErrClass”: “database”,
“ErrScope”: “not-set”,
“ErrLevel”: “high”,
“Message”: “startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.001311, 253828172), gtid-set: b6e72963-f79a-11e8-a58e-bc3f8ff8605c:1-161155243,2f5ed759-54ea-11e8-8314-246e965f5e28:1,fa1932de-4baf-11ea-9a39-f875884a3c52:1-833451899,0778d74d-4bb0-11ea-a846-446a2e8b5372:1-4,2712b16c-54ea-11e8-8924-246e965f6be0:1-6,c42f1e56-b415-11e9-9b6f-f875884a3946:1-274069043,f73192cd-cb89-11e8-92e9-f875884a395c:1-8187722,a003b8d3-54eb-11e8-9eb6-f875884a3986:1-25767130,c67caf45-f79a-11e8-a02b-a0a33bc4c267:1-6676546,a889b6d1-54eb-11e8-880d-6c92bf48d024:1-142]: execute statement failed: REPLACE INTO insurance.ins_distribute_gift_detail (id,distribute_code,policy_num,gift_detail,remark,created_at,updated_at,deleted_at) VALUES (?,?,?,?,?,?,?,?)”,
“RawCause”: “Error 1048: Column ‘remark’ cannot be null”,
“Workaround”: “”
}
]

已知原始语句为 insert into 语句,切该字段在mysql中设置为 not null default ‘’。

dm worker程序的stdout日志如下:
[2021/01/25 17:11:44] [info] binlogsyncer.go:144 create BinlogSyncer with config {429546496 mysql 172.16.0.220 3306 dm_user false false false Asia/Shanghai true 0 30s 1m0s 1 true true 0}
[2021/01/25 17:11:44] [info] binlogsyncer.go:377 begin to sync binlog from GTID set a003b8d3-54eb-11e8-9eb6-f875884a3986:1-25767130,a889b6d1-54eb-11e8-880d-6c92bf48d024:1-142,fa1932de-4baf-11ea-9a39-f875884a3c52:1-833440376,f73192cd-cb89-11e8-92e9-f875884a395c:1-8187722,c67caf45-f79a-11e8-a02b-a0a33bc4c267:1-6676546,c42f1e56-b415-11e9-9b6f-f875884a3946:1-274069043,0778d74d-4bb0-11ea-a846-446a2e8b5372:1-4,b6e72963-f79a-11e8-a58e-bc3f8ff8605c:1-161155243,2712b16c-54ea-11e8-8924-246e965f6be0:1-6,2f5ed759-54ea-11e8-8314-246e965f5e28:1
[2021/01/25 17:11:44] [info] binlogsyncer.go:776 rotate to (mysql-bin.001311, 4)
[2021/01/25 17:11:47] [info] binlogsyncer.go:175 syncer is closing…
[2021/01/25 17:11:47] [error] binlogstreamer.go:77 close sync with err: sync is been closing…
[2021/01/25 17:11:47] [error] binlogsyncer.go:843 kill connection 55906198 error ERROR 1094 (HY000): Unknown thread id: 55906198
[2021/01/25 17:11:47] [info] binlogsyncer.go:849 kill last connection id 55906198
[2021/01/25 17:11:47] [info] binlogsyncer.go:202 syncer is closed

求解,困扰了我好几天了。

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

你好,

  • 1.可以反馈下 下游 TiDB 数据库中的表结构么 insurance . ins_distribute_gift_detail
  • 2.看一下 remark 字段的字段类型。可以手动测试下 insert 语句是否成功插入到下游数据库中。

另外 DM 的版本目前最高是 2.0.1 版本,并不存在 v1.3.1 版本;如果使用 tiup 部署,可以使用 tiup dm list 来确认下 dm 的版本;
原始语句为 insert into,但是 显示的是 replace into,任务开始前五分钟内,会自动开启 safe-mode 模式。

safe-mode 设置为 true,则将来自上游的 `INSERT` 改写为 `REPLACE`,将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`,保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 5 分钟内 TiDB DM 会自动启动 safe mode
2 个赞

tiup dm list 的执行结果

op@tx-bj3-236-5:~$ tiup dm list
Starting component dm: /home/op/.tiup/components/dm/v1.3.1/tiup-dm list
Name User Version Path PrivateKey


tidb-xiaobang tidb nightly /home/op/.tiup/storage/dm/clusters/tidb-xiaobang /home/op/.tiup/storage/dm/clusters/tidb-xiaobang/ssh/id_rsa

表结构:ins_distribute_gift_detail
| ins_distribute_gift_detail | CREATE TABLE ins_distribute_gift_detail (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘主键id’,
distribute_code varchar(32) NOT NULL DEFAULT ‘’ COMMENT ‘派发礼品单编号’,
policy_num varchar(32) NOT NULL DEFAULT ‘’ COMMENT ‘保单号’,
gift_detail varchar(1024) NOT NULL DEFAULT ‘’ COMMENT ‘礼品详情’,
remark varchar(128) NOT NULL DEFAULT ‘’ COMMENT ‘其他补充信息’,
created_at int(11) NOT NULL DEFAULT 0 COMMENT ‘创建时间’,
updated_at int(11) NOT NULL DEFAULT 0 COMMENT ‘更新时间’,
deleted_at int(11) NOT NULL DEFAULT 0 COMMENT ‘删除时间’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=34523

麻烦确认下手动插入是否成功?

  • 1.nightly 版本不稳定,建议使用 2.0.1 稳定版本。如再有问题,可以提供下 dm-worker.log 一起看下。

dm task 的配置文件可以提供一下?

nightly版本已经升级到了 2.0.1 版本,但还是会出这个问题

dm-worker.log 内容如下:

dm task 的配置文件如下:

insert into 命令我也测试了,可以成功插入

再请教几个问题

1.查看一下源数据库的 binlog_row_image 值是什么,show variables like ‘%row_im%’;
2.查看一下源数据库 binlog position (mysql-bin.001311, 253824787) 附近的的 binlog 内容,可以通过 bin/mysqlbinlog mysql-bin.001311 解析 binlog 文件,找到 253824787 附近的 binlog

如果方便的话,提供一下以上信息

binlog_row_image 的值是 FULL,这个在同步前是特别设置过的,如果不是FULL,同步任务都启动不了

mysql-bin.001311, 253824787 这个时间有点儿长,binlog文件已经没了。我重置一下同步任务吧

目前情况如何@syl0735
如果上下有表结构一致的话,不应该出现这种情况。

更新一下进度:
根据 @小王同学 的建议,把版本都升级到了最新版,然后把数据都清理掉,重新同步,已经运行了3天,到目前为止,还没有复现上边遇到的错误,也没有出现其他的错误

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

如果还有其他问题,可重新开帖 ~~~

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