【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5.8
【遇到的问题：问题现象及影响】
上游mysql数据同步到tidb集群。把mysql库里的分表合并同步到tidb集群。比如mysql表t1_01,t1_02,tidb里的表t1.
之前同步都是正常的，由于上游mysql里的分表修改了部分字段的数据类型。导致同步任务中断。
“syncerBinlog”: 不动
“unsynced”: 提示未同步的分表信息
“synced”: false
目前已经手动更新了tidb里的表结构。请问该如何处理？
看下
tiup dmctl query-status XXX
重启同步任务试试
就是查看状态才知道反馈里的信息的。
试过了。不行。
我记得这种情况，task报错信息里面应该会提示你使用
tiup dmctl operate-schema
或者
tiup dmctl binlog-schema
https://docs.pingcap.com/zh/tidb/stable/dm-manage-schema#命令介绍
需要手动更新一下dm里面记录的表的结构。具体你可以看看上面这个文档。
一次性同步？
有没有日志，进程正常不
这个兄台说的对，手动更新dm 记录的表结构
错误的之前已经跳过了。状态是running的。就是sync阶段卡住了。
subTaskStatus": [
{
“name”: “dmtask_001”,
“stage”: “Running”,
“unit”: “Sync”,
“result”: null,
“unresolvedDDLLockID”: “”,
“sync”: {
“totalEvents”: “9753”,
“totalTps”: “0”,
“recentTps”: “0”,
“masterBinlog”: “(dd-mysql-1-bin.000489, 86754522)”,
“masterBinlogGtid”: “”,
“syncerBinlog”: “(dd-mysql-1-bin.000488, 190527979)”,
“syncerBinlogGtid”: “00000000-0000-0000-0000-000000000000:0”,
“blockingDDLs”: [
],
“unresolvedGroups”: [
{
“target”: “mydb.t1”,
“DDLs”: [
"ALTER TABLE mydb.t1 CHANGE COLUMN after_star_amount after_star_amount INT(11) DEFAULT 0 NOT NULL "
],
“firstLocation”: “position: (dd-mysql-1-bin.000488, 190527979), gtid-set: 00000000-0000-0000-0000-000000000000:0”,
“synced”: [
“weplay.t1_202403”
],
“unsynced”: [
“mydb.t1_202404”,
“mydb.t1_202405”,
“mydb.t1_202406”,
]
}
],
“synced”: false,
“binlogType”: “remote”,
“secondsBehindMaster”: “0”,
“blockDDLOwner”: “”,
“conflictMsg”: “”,
“totalRows”: “9753”,
“totalRps”: “0”,
“recentRps”: “0”
},
“validation”: null
}
binlog skip taskname
再跳三次，因为你是合库合表场景，ddl需要执行4次，你需要跳过4次，你只跳了一次。
这个跳不过去。状态已经是running了。
bug问题吗,反馈一下
更新一下TIDB里面的表结构，重新同步呢？
tidb里的表结构已经手动更新过。现在主要就是任务是正常running的。但syncbinlog卡住不动了。
我自己遇到一个也是表结构不一致同步失败，自己手动修改表结构，stop任务start任务没有用。必须使用binlog-schema更新表结构才行，参考：https://docs.pingcap.com/zh/tidb/stable/migrate-with-more-columns-downstream#使用-dm-迁移至存在更多列的下游
我操作过的方案
在dm服务器上创建和上游一样的表结构slq
vim 1.sql
[tidb@dm1 log]$ cat /home/tidb/1.sql
CREATE TABLE TCCORE_PROD.tmp_20240328_userid (
AM_WALLET_ID char(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT ‘’,
USER_ID char(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
PRIMARY KEY (AM_WALLET_ID) USING BTREE,
INDEX USER_ID(USER_ID(20)) USING BTREE)
2.手动使用binlog-schema更新表结构
tiup dmctl --master-addr=192.168.1.xxx:8261 binlog-schema update -s db31 mysql-tidb -d tccore_prod -t tmp_20240328_userid 1.log
3.执行恢复任务
tiup dmctl --master-addr=192.168.3.233:8261 resume-task mysql-tidb
查看状态：
tiup dmctl --master-addr=192.168.3.233:8261 query-status
https://docs.pingcap.com/zh/tidb/stable/manually-handling-sharding-ddl-locks
你看看这个。这个报错的原因是
“unsynced”: [
“mydb.t1_202404”,
“mydb.t1_202405”,
“mydb.t1_202406”,
]
这几个上游表的表结构可能没改，这些提前建立的表对应的字段类型可能还是老的。因为涉及到分片合并所以被dm的ddl 锁定。
如果确定不需要修改了，也不会有数据进去，就直接考虑按照文档写的那样unlock这个ddl lock。
mysql里的那几个分表，结构是修改过的。开始使用binlog skip，但任务恢复不了。然后我就用binlog-schema把dm里这些分表信息都给删了。任务还是跑不起来。dm同步任务里，查看过，没有锁。看来只有指定binlog点位，同步了。这样的话。数据又对不上了。
tiup dmctl shard-ddl-lock dmtask_001
是什么结果？
指定binlog点位，重新同步肯定是可以的。
还有就是可以把上游经常变动的表放到一个专门的任务里面去。
这样某几个经常改来改去的表发生变动不会影响其他表的同步。
上游要是用的随意，下游就是遭罪。
能做的只能是把经常出问题的表放一起。别影响其他没问题的表。
{
“result”: true,
“msg”: “no DDL lock exists”,
“locks”: [
]
}