dm订阅mysql8出现Column 'id' cannot be null

【 TiDB 使用环境】
5.7.25-TiDB-v5.0.1-1-g35276ad
dm-2.0.3

【概述】 场景 + 问题概述

订阅腾讯云 mysql8 实例中的某库的业务表的update event 出现 Column ‘id’ cannot be null

【现象】 业务和数据库现象
以下是dm-work日志(敏感内容替换成了xxxx)

[2021/09/08 10:10:31.627 +08:00] [ERROR] [db.go:277] [“execute statements failed after retry”] [task=task-prod-qiqiao-plus2] [unit=“binlog replication”] [queries="[UPDATE bxxxx-rxxxx-xxxx.f_危机_714b7a2054b3c1b0_ad340 SET author_name = ?, last_modifier_name = ?, last_modify_date = ?, author = ?, process_instance_id = ?, id = ?, version = ?, last_modifier = ?, createDate = ?, 相关附件 = ?, 关联客户 = ?, corpid = ?, 盘点时间 = ?, 危机类型 = ?, 访谈情况 = ?, 攻坚建议 = ?, 反馈时间 = ?, 挽回难度 = ?, 回访情况反馈 = ?, 负责人 = ?, 所属区域 = ?, 负责人_pretty_value = ?, 测试 = ?, 组长_pretty_value = ?, 组长 = ?, 危机后果 = ?, 需要什么攻坚支持 = ? WHERE id = ? LIMIT 1 UPDATE bpms-runtime-plus2.f_危机_714b7a2054b3c1b0_ad340 SET author_name = ?, last_modifier_name = ?, last_modify_date = ?, author = ?, process_instance_id = ?, id = ?, version = ?, last_modifier = ?, createDate = ?, 相关附件 = ?, 关联客户 = ?, corpid = ?, 盘点时间 = ?, 危机类型 = ?, 访谈情况 = ?, 攻坚建议 = ?, 反馈时间..."] [arguments="[[<nil> xxxx 2021-09-08 10:10:31 <nil> <nil> <nil> 4 b084e787d2c35cb4e7640383d2daf203 <nil> <nil> c00c0ca756d8405abe4cd39e014cf743 xxxx 2021-08-26 7 [231 155 174 229 137 141 228 189 191 231 148 168 233 163 158 228 185 166] [230 178 159 233 128 154 228 184 139 232 180 185 230 142 167 230 138 165 233 148 128] 2021-09-10 1 [] 8dfd2e9f1f6214da72962fd65ef82db8 2 [233 152 179 231 186 162 232 137 179] 4 [229 189 173 230 179 189 231 186 175] cc23220dda26fad3271275c6bbc1a8e2 <nil> <nil> 0086af21dd40400b91f30b9d0bf379b9] [<nil> xxxx 2021-09-08 10:10:31 <nil> <nil> <nil> 4 b084e787d2c35cb4e7640383d2daf203 <nil> <nil> 13f8b15ec8ec4563b3cada9bff67838f xxxx 2021-08-18 6 [230 181 183 229 164 150 229 184 130 229 156 186 230 181 183 232 158 186 228 188 129 228 184 154 239 188 140 49 57 229 185 180 231 187 173 231 186 166 229 144 142 229 174 162 230 136 183 229 143 141 233 166 136 229 183 178 231 187 143 228 189 191 231 148 168 232 135 170 231 160 148 231 179 187 231 187 159 227 128 130] [..."] [error="[code=10006:class=database:scope=not-set:level=high], Message: execute statement failed: UPDATEbpms-runtime-plus2.f_危机_714b7a2054b3c1b0_ad340SETauthor_name= ?,last_modifier_name= ?,last_modify_date= ?,author= ?,process_instance_id= ?,id= ?,version= ?,last_modifier= ?,createDate= ?,相关附件= ?,关联客户= ?,corpid= ?,盘点时间= ?,危机类型= ?,访谈情况= ?,攻坚建议= ?,反馈时间= ?,挽回难度= ?,回访情况反馈= ?,负责人= ?,所属区域= ?,负责人_pretty_value= ?,测试= ?,组长_pretty_value= ?,组长= ?,危机后果= ?,需要什么攻坚支持= ? WHEREid` = ? LIMIT 1, RawCause: Error 1048: Column ‘id’ cannot be null"]

对比上游库,并未发现id字段有null值, id字段为主键。且整行数据为null字段只有4个。

上下游表结构对比

发一下 dm的配置

tmp-task.yaml (954 字节)

上游mysql的binlog 关于这一条的信息也发一下 以及上游mysql的binlog格式是什么?

感谢提醒。目前查到
binlog_row_image MINIMAL 这个值不为full
binlog_format ROW

ok 需要修改 确定连接都已经是 full ,重新同步即可。

感谢反馈,我们会在 https://github.com/pingcap/dm/issues/2091 讨论和修复该问题

请问这个值为什么是 MINIMAL 呢,是您使用的 RDS 的默认值吗,还是有什么业务考量

rds的默认值,原来用的实例是full,这个是新买的实例,就没检查是否full

1赞

如果是 global 级别的变量不为 FULL 的话,DM 会有一个前置检查

https://docs.pingcap.com/zh/tidb-data-migration/stable/precheck#上游-mysql-实例配置前置检查

“ * 是否有 binlog_row_image=FULL (DM 只支持 binlog_row_image=FULL )”

是配置了跳过这个检查吗

是的。task当时是直接从订阅旧实例移植过来的。关键检查,建议还是默认不可关闭吧。