上游Mysql对表进行了truncate操作,下游tidb怎么自动同步到该操作(包含分表合并场景)

,

上游Mysql对表进行了truncate操作,下游tidb中的对应表发现并未同步进行truncate清理掉全部数据;分表合并的场景,清理掉上游的部分参与合并的表,下游tidb中合并后的总表也是没有反应。这种是需要怎么配置呢?

【TiDB 使用环境】/测试环境
【TiDB 版本】8.5.2
【部署方式】 机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】如下日志,并非报错,看着是被skip了
[2026/02/03 14:46:36.913 +08:00] [INFO] [ddl.go:329] [“resolve sql”] [task=task-test1] [unit=“binlog replication”] [component=ddl] [event=query] [appliedDDLs=“["TRUNCATE TABLE app.apptest"]”] [queryEventContext=“{schema: app, originSQL: truncate table apptest, startLocation: position: (binlog.007657, 221184469), gtid-set: 00000000-0000-0000-0000-000000000000:0, endLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, lastLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, re-sync: , needHandleDDLs: , trackInfos: }”]
[2026/02/03 14:46:36.913 +08:00] [INFO] [ddl.go:496] [“filter truncate table statement in shard group”] [task=task-test1] [unit=“binlog replication”] [component=ddl] [mode=pessimist] [event=query] [statement=“TRUNCATE TABLE app.apptest”]
[2026/02/03 14:46:36.913 +08:00] [INFO] [ddl.go:390] [“prepare to handle ddls”] [task=task-test1] [unit=“binlog replication”] [component=ddl] [event=query] [queryEventContext=“{schema: app, originSQL: truncate table apptest, startLocation: position: (binlog.007657, 221184469), gtid-set: 00000000-0000-0000-0000-000000000000:0, endLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, lastLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, re-sync: , needHandleDDLs: , trackInfos: }”]
[2026/02/03 14:46:36.913 +08:00] [INFO] [ddl.go:392] [“skip event, need handled ddls is empty”] [task=task-test1] [unit=“binlog replication”] [component=ddl] [event=query] [queryEventContext=“{schema: app, originSQL: truncate table apptest, startLocation: position: (binlog.007657, 221184469), gtid-set: 00000000-0000-0000-0000-000000000000:0, endLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, lastLocation: position: (binlog.007657, 221184559), gtid-set: 00000000-0000-0000-0000-000000000000:0, re-sync: , needHandleDDLs: , trackInfos: }”]
【其他附件:截图/日志/监控】

手动对齐吧,这种复杂的 DDL 估计支持不了

手动对齐后,在重新开启同步

https://docs.pingcap.com/zh/tidb/stable/quick-start-with-dm/#第-4-步创建-tidb-dm-任务

这个链接里面,找找看有没有解决办法

只有在以下前提下:

没有 table routing

没有 shard merge

上游表 = 下游表

你才可以:

[sink]
dispatchers = [
{matcher = [“db.*”], dispatcher = “table”}
]

并不屏蔽 TRUNCATE DDL

手动修改啊

1 个赞

dm感觉要支持这种drop/truncate table技术上应该是没啥难度的,可能是有其他方面的考虑不支持。基于binlog的数据同步比较难的是加/减字段才对