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

  • 【TiDB 版本】:v3.0.10,dm v1.0.3
  • 【问题描述】:

上游mysql大表早上5点执行加字段,pt工具执行,tidb这边知道中午12点左右才同步追上。

我看了tidb集群监控,常规的cpu、内存、io,在5点至12点期间没发现太高的值

请问这个需要怎么排查瓶颈点?

3个kv节点都是16核32G,pd与tidb共用16核32核机器

尝试调大 task 文件中 syncer 部分的参数

task文件syncer更新,是不是不支持在线更改?

如果不支持在线更新,我是不是要在停止同步任务时,记录下当前的binlog信息,然后修改完再从记录的binlog位点,用增量同步的方式开启?

stop task 再 start task,可以生效,不会从头重做 (不要设置 remove-meta: true)。

好的,谢谢

: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任务瞬间完成的