DM同步任务重复dump问题

可以先调大下连接的参数,再用 mydumper 看下是否可以导出。
如果不行,先用 dumpling 导出下,他有 debug 日志,好分析一些。

2.0 dm 将 mydumper 换成了 dumping,只是为了好分析先执行看下吧。

中午用dumpling导了一下,是可以导出来的,日志如下:然后马上用dm工具重跑task,但还是无法dump成功。

dumpling日志.txt (64.2 KB)

你好看下 20200908 08:43:10 时间点附近,mysql log 是否有异常,mydumper 对 client 部分的报错不是很多。
dumpling 的 log 我们看了下,没有明显的报错。

上面反馈之后,更新 task 配置:
mydumpers:
mysql-replica-06.dump:
mydumper-path: bin/mydumper
threads: 8
skip-tz-utc: true
extra-args: -r 1000 --no-locks

再试下,缩小了 -r,去掉了 chuck size

对于MySQL server has gone away,之前周三的时候找过dba那边确认,他们反馈没有异常……
image

修改参数后重试,现在也还是一直重dump
[2020/09/11 15:39:18.564 +08:00] [ERROR] [mydumper.go:170] [“Error dumping schemas (hdb_broker_9.broker_client_history): MySQL server has gone away”] [task=broker_client_history] [unit=dump]

一个绕过方法就是 dumpling 先导出,然后 DM 根据 dumpling 的 meta 设置 pos 点

进行 increment-mode 同步

PS:升级到 dm 2.0 也可以,已经将 mydumper 换成咱们自研的 go dumpling 了。

也额外补充一下。DM 2.0 对于类似 “MySQL server has gone away” 这样的导出错误,也默认就不会触发 task checker 的自动恢复(也就是说不会自行去尝试无意义的重复导出)

感觉暂时用第一种方法会好点,但还是不清楚具体是如何修改配置并进行增量同步,能提供详细点的方案吗,谢谢。

是不是通过导出来的这个文件确定binlog的点位

cat metadata
Started dump at: 2020-09-11 11:19:11
SHOW MASTER STATUS:
Log: mysql-bin.000698
Pos: 316866204

然后在task任务配置中修改下面2个地方:
task-mode: increment

mysql-instances:

  • source-id: mysql-replica-06
    meta:
    binlog-name: mysql-bin.000698
    binlog-pos: 316866204

增量同步任务, 是指通过 binlog 把上游数据库的增量修改复制到下游数据库, 可以设置实例配置的 meta 配置项来指定增量复制开始的位置。
需要配置两个地方

  • task-mode:设置模式为 incremental
  • meta:补充增量同步的起始位点

https://github.com/pingcap/dm/blob/e5dc3372d20e57fbc9a90f8860bde96e529bee77/dm/dm-ansible/conf/task_advanced.yaml.example#L27-L29

那我dump下来的全量文件还没有入库,这一点是通过手工入库么?

对的,需要全量数据手动导入后,再进行增量数据同步。
全量数据导入可以使用 lightning

1赞

确认下,不管是下面哪种模式,只要lightning运行,tidb都无法对外提供服务吗?

还有一个问题,上游mysql是分库分表,导出来的文件是分库的,需要导入下游的一张表内,这种场景下,需要如何操作?

你好,不同问题麻烦重新开帖提问,多谢。
另外你上面两个 lightning 问题,除了 tidb-backend 后端模式不会有影响,另外两个模式都是对 TiDB 有影响的,另外第二个问题可以参考文档配置 routes