上游mysql ddl,dm同步延迟近7个小时

好的,谢谢

:handshake:

syncer我已经修改了,任务也stop、start了,但是发现延迟还是一直在增加。我怎么知道我修改生效了呢?

image

可以看下 task 启动后 dm worker 日志中打印的内容,另外关注下监控 dm worker 监控的 finished sqls jobs 单位时间处理的任务数量是否增加。

看了下worker打印的日志,是生效了。但是同步任务还是很慢

看了下finished sqls jobs没怎么增加,延迟倒是很大,这个问题是tidb集群写入问题吗?

检查监控 TiDB Dashboard 的 Duration 延迟,以及 tidb slow query 日志中同步相关的慢查询信息。

我查询了information schema下的slow_query表,没有查询到DB名称等于现在同步的这个库名

在tidb那台机器的log目录下,找到slow log,发现最后一条就是上游mysql在ddl操作,后面就没有慢sql了。 时间点:上游mysql是凌晨3点定时任务ddl操作

看起来是下游 TiDB 执行 DDL 慢了,DM 要等 DDL 执行完成后才能继续同步,可以通过 SQL admin show ddl jobs, 看看对应 DDL 执行的结束时间是不是12点。因为 DM 是可以自动追上的,所以瓶颈应该不在 DM

这个算正常吗?哪里可以看到ddl完成时间?

tidb集群,cpu、内存、io都不高啊

show processlist发现,insert into 只有一个连接(插入正在ddl的这个表),且是单条插入非批量插入,正常的话,连接应该会有很多,大批量的插入

1、从监控 qps 看 insert 是正常的且 duration 比较低,show processlist 看不到 insert 的连接应该也是正常的;

2、过滤下 tidb 的日志 jobId=3984,看 ddl 操作实际完成的时间。

日志中实际的表都用xxx代替了,看着3984任务瞬间完成的

好的,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谢谢周末一直在支持:+1:

此问题已经解决,问题是在配置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,现在的方案得到解决,请点击最佳解决方案。