上游mysql 执行DDL，DM同步下游到TIDB报错

[LKLK]

V5.4.1 集群版本，上游mysql 执行DDL，DM同步下游到TIDB报错，请问要如何解决呀？
{
“result”: true,
“msg”: “”,
“sources”: [
{
“result”: true,
“msg”: “”,
“sourceStatus”: {
“source”: “xxxx”,
“worker”: “xxx”,
“result”: null,
“relayStatus”: null
},
“subTaskStatus”: [
{
“name”: “pay”,
“stage”: “Running”,
“unit”: “Sync”,
“result”: null,
“unresolvedDDLLockID”: “”,
“sync”: {
“totalEvents”: “15928709”,
“totalTps”: “49777”,
“recentTps”: “0”,
“masterBinlog”: “(mysql-bin.000021, 14947773)”,
“masterBinlogGtid”: “0-1453306-3023561378”,
“syncerBinlog”: “(mysql-bin.000019, 677578533)”,
“syncerBinlogGtid”: “0-1453306-3022111539”,
“blockingDDLs”: [
“ALTER TABLE snspaycenter.t_paymethod CHANGE COLUMN pm_show_name pm_show_name VARCHAR(60) CHARACTER SET UTF8 COLLATE utf8_general_ci NOT NULL DEFAULT _UTF8MB4’’ COMMENT ‘对外名称’”
],
“unresolvedGroups”: [
{
“target”: “snspaycenter.t_paymethod”,
“DDLs”: [
“ALTER TABLE snspaycenter.t_paymethod CHANGE COLUMN pm_show_name pm_show_name VARCHAR(60) CHARACTER SET UTF8 COLLATE utf8_general_ci NOT NULL DEFAULT _UTF8MB4’’ COMMENT ‘对外名称’”
],
“firstLocation”: “position: (mysql-bin.000019, 677578575), gtid-set: 0-1453306-3022111539”,
“synced”: [
“snspaycenter.t_paymethod”
],
“unsynced”: [
]
}
],
“synced”: false,
“binlogType”: “remote”,
“secondsBehindMaster”: “74983”
}
}
]
}
]
}

【附件】

请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。

[db_user]

请问你这个变更是变更的什么，变更varchar长度（变短）还是说更改字符集，可以把对应的sql去下游tidb执行，看报什么错，tidb目前没有和mysql100%兼容

[LKLK]

把几个字段改成了 not null
ALTER TABLE snspaycenter.t_paymethod CHANGE COLUMN pm_alias pm_alias VARCHAR(60) CHARACTER SET UTF8 COLLATE utf8_general_ci NOT NULL DEFAULT _UTF8MB4’’ COMMENT ‘后台名称’;
ALTER TABLE snspaycenter.t_paymethod CHANGE COLUMN pm_show_name pm_show_name VARCHAR(60) CHARACTER SET UTF8 COLLATE utf8_general_ci NOT NULL DEFAULT _UTF8MB4’’ COMMENT ‘对外名称’;

在tidb执行错误提示

ERROR 1265 (01000): Data truncated for column ‘pm_show_name’ at row 1

[db_user]

@LKLK

ALTER TABLE snspaycenter . t_paymethod CHANGE COLUMN pm_show_name pm_show_name VARCHAR(60) CHARACTER SET UTF8 COLLATE utf8_general_ci NOT NULL DEFAULT _UTF8MB4

这个语句在下游执行没有报错么，看起来是报错的语句啊,如果执行成功了可能是因为当时死锁的情况导致执行失败，可以重新stop-task,start-task观察是否报错，如果报错找不到对应的二进制文件，那就是二进制文件保留时间比较短，需要重新同步下了

[LKLK]

是执行报错了啊，现在要如何处理啊？重新做这个表的同步？如何针对单表的重新同步啊？整个库数据量很大，线上业务

[jerry]

如果这张表是多表合一，是不是应该考虑下。是不是某些分表没有加索引 导致的、

[xiaohetao (Becky)]

@LKLK

ERROR 1265

看下是否和精度有关

[db_user]

可以跳过出错的DDL语句
https://docs.pingcap.com/zh/tidb/v5.4/handle-failed-ddl-statements

不过这样会导致上下游表结构不一致，最好是暂停任务，然后调整下游表结构，然后跳过出错的DDL

[Hacker007]

ddl语句可以跳过的，跳过以后你可以在下游手动执行
https://docs.pingcap.com/zh/tidb/v5.4/handle-failed-ddl-statements

[LKLK]

我使用了handle-error test skip ，提示no errors 。。。奇怪了

[Hacker007]

还报错？skip只能跳过ddl语句，要是还有异常resume试下

[LKLK]

都试了，还是不行

[LKLK]

还有咨询下我重建集群，但dm全量同步是依然是使用默认字符集，没有继承mysql的字符集，这个bug 官方修复了吗？

[Hacker007]

全量的不会继承

[Hacker007]

每次skip只会跳过一个异常，你确认下是不是有多个语句错误，可以多执行几次

[LKLK]

那这个要咋处理？

[LKLK]

官方修复了

colation_compatible: “loose” # 同步 CREATE 语句中缺省 Collation 的方式，可选 “loose” 和 “strict”，默认为 “loose”。“loose” 模式不会显式补充上游缺省的 Collation，“strict” 会显式补充上游缺省的 Collation。当使用 “strict” 模式，但下游不支持上游缺省的 Collation 时，下游可能会报错。

[Hacker007]

不行的，增量的可以，我这边都测过了

[Hacker007]

而且继承上游的排序规则会有很多问题的