好的，DDL 没问题，检查下 dm worker 的日志是否有异常；如果没有发现异常，可以开启 debug 日志，dm-worker 进程启动加上 -L debug
这里的意思是每天执行变更的时候，都会有一段时间延迟增加对吗？
周一执行一个大表DDL，然后tidb延迟7个小时左右才追上上游mysql
今天凌晨3点再次执行一个大表DDL，到目前为止已经延迟14个小时，还没有有同步追上。这次严重的是tidb中的数据还是3点多的数据，相当于这十几个小时就等于没有同步数据
pt 执行变更的时候，会产生大量 row events，dm 会将临时表的 row events 会丢弃，如果下游数据一直没有更新，且状态正常，可能现在处在丢弃阶段，过滤下 dm worker 日志中的 DDL 关键字看下 pt 相关的 DDL 信息。
@qizheng-PingCAP谢谢周末一直在支持
此问题已经解决，问题是在配置task配置文件时没有加 online-ddl-scheme: “pt” 这个过滤条件，导致最终上游mysql大表ddl操作卡住。
文件添加位置：
因为我这是中途加入这个参数，所以已经有部分操作不可逆了，只能选择跳过卡住的binlog位点。
在跳过binlog这个操作上使用 sql-skip 或者 sql-replace 两个都不起作用，最后是通过修改tidb中的dm_meta库来跳过，具体就是修改dm_meta库中 xxxx_syncer_checkpoint表中is_global = 1这条记录
目前在官方文档中没有找到针对pt工具的处理，希望文档能尽快补上这个参数 online-ddl-scheme: “pt” 相关的操作说明
1 个赞
好的，如果新的问题，麻烦创建新的 issue，现在的方案得到解决，请点击最佳解决方案。
这个问题我遇到过，设置为pt并不能覆盖所有场景
如果是操作索引，即使 online-ddl-scheme: “pt”，则DM依然会阻塞，阻塞时间为tidb完成索引的时间。当tidb完成索引修改后，DM才会接着想tidb同步数据
1 个赞
感谢提醒。如果希望 pt 的 online DDL 原样同步过来的话，需要在黑白名单中将 pt 产生的临时表加到白名单中，并且不配置 online-ddl-scheme，这样预期是可以将上游的临时表同步过来的
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。