可以先调大下连接的参数，再用 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:
- source-id: mysql-replica-06
meta:
binlog-name: mysql-bin.000698
binlog-pos: 316866204
增量同步任务， 是指通过 binlog 把上游数据库的增量修改复制到下游数据库, 可以设置实例配置的 meta 配置项来指定增量复制开始的位置。
需要配置两个地方
- task-mode：设置模式为 incremental
- meta：补充增量同步的起始位点
那我dump下来的全量文件还没有入库，这一点是通过手工入库么？
对的，需要全量数据手动导入后，再进行增量数据同步。
全量数据导入可以使用 lightning
https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-backends
1 个赞
你好，不同问题麻烦重新开帖提问，多谢。
另外你上面两个 lightning 问题，除了 tidb-backend 后端模式不会有影响，另外两个模式都是对 TiDB 有影响的，另外第二个问题可以参考文档配置 routes
https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-backends#从-loader-迁移到-tidb-lightning-tidb-backend