可以先调大下连接的参数,再用 mydumper 看下是否可以导出。
如果不行,先用 dumpling 导出下,他有 debug 日志,好分析一些。
2.0 dm 将 mydumper 换成了 dumping,只是为了好分析先执行看下吧。
可以先调大下连接的参数,再用 mydumper 看下是否可以导出。
如果不行,先用 dumpling 导出下,他有 debug 日志,好分析一些。
2.0 dm 将 mydumper 换成了 dumping,只是为了好分析先执行看下吧。
你好看下 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那边确认,他们反馈没有异常……
修改参数后重试,现在也还是一直重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:
增量同步任务, 是指通过 binlog 把上游数据库的增量修改复制到下游数据库, 可以设置实例配置的 meta
配置项来指定增量复制开始的位置。
需要配置两个地方
那我dump下来的全量文件还没有入库,这一点是通过手工入库么?
对的,需要全量数据手动导入后,再进行增量数据同步。
全量数据导入可以使用 lightning
https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-backends
你好,不同问题麻烦重新开帖提问,多谢。
另外你上面两个 lightning 问题,除了 tidb-backend 后端模式不会有影响,另外两个模式都是对 TiDB 有影响的,另外第二个问题可以参考文档配置 routes
https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-backends#从-loader-迁移到-tidb-lightning-tidb-backend