好的，谢谢
上游mysql ddl，dm同步延迟近7个小时
syncer我已经修改了，任务也stop、start了，但是发现延迟还是一直在增加。我怎么知道我修改生效了呢？
可以看下 task 启动后 dm worker 日志中打印的内容，另外关注下监控 dm worker 监控的 finished sqls jobs 单位时间处理的任务数量是否增加。
检查监控 TiDB Dashboard 的 Duration 延迟，以及 tidb slow query 日志中同步相关的慢查询信息。
看起来是下游 TiDB 执行 DDL 慢了，DM 要等 DDL 执行完成后才能继续同步，可以通过 SQL
admin show ddl jobs, 看看对应 DDL 执行的结束时间是不是12点。因为 DM 是可以自动追上的，所以瓶颈应该不在 DM
show processlist发现，insert into 只有一个连接（插入正在ddl的这个表），且是单条插入非批量插入，正常的话，连接应该会有很多，大批量的插入
1、从监控 qps 看 insert 是正常的且 duration 比较低，show processlist 看不到 insert 的连接应该也是正常的；
2、过滤下 tidb 的日志 jobId=3984，看 ddl 操作实际完成的时间。
好的，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，现在的方案得到解决，请点击最佳解决方案。