从tidb导出数据，然后导入mysql后 ，drainer报错

[qhd2004]

tidb版本是v4.0.0
我把tidb中数据导出来，然后导入到它的下游库（mysql）中，使用drainer进行同步时，发现报错。

1，导出
/home/appadmin/tidb-tools/bin/mydumper --ask-password -h 10.10.10.10 -P 3306 -u root --threads=4 --chunk-filesize=64 --skip-tz-utc --regex ‘^(?!(mysql.|information_schema.|performance_schema.|metrics_schema.|tidb_loader.))’ -o /home/appadmin/dump_data/ --verbose=3

cat metadata
Started dump at: 2020-06-08 18:14:57
SHOW MASTER STATUS:
Log: tidb-binlog
Pos: 417231351902896131
GTID:

Finished dump at: 2020-06-08 18:15:01

2，导入mysql中
/home/appadmin/tidb-tools/bin/loader -d /home/appadmin/dump_data/ -h 10.10.10.205 -u drainer -p drainer_supersecret -P 3306 -t 2

3，修改yaml文件
tiup cluster edit-config tidb-db
drainer_servers:

• host: 10.10.10.72
  ssh_port: 22
  port: 8249
  deploy_dir: /data/deploy/drainer
  data_dir: data/drainer-8249
  log_dir: /data/deploy/drainer/log
  config:
  initial-commit-ts: 417231351902896131
  syncer.db-type: mysql
  syncer.to.host: 10.90.10.205
  syncer.to.password: drainer_supersecret
  syncer.to.port: 3306
  syncer.to.user: drainer
  arch: amd64
  os: linux

4，reload后查看是正常
tiup cluster reload tidb-db --role drainer
tiup cluster display tidb-db

5，一段时间后报错，日志如下：

我有几个问题：
1，我在yaml中指定了pos，那我第一次reload时，是从这个pos开始向后应用日志，对吧？如果我再次重启drainer或是重启整个集群，那应用日志是还有这个pos开始，还是从下游mysql中的tidb_binlog库checkpoint表中的commitTS对应的值开始呢？

2，我看了drainer的日志，发现ignore ddl，表对象已经存在了为什么还要再create 一下呢？

3，对主外键约束的处理，不太明白，为什么表中没有这些，但日志中却有添加约束呢？

[yilong (yi888long)]

1. 如果有checkpoint，会从checkpoint走
   

   

2. 您是说下游表对象已经存在了？ 这个drainer并不知道，他要执行了判断后才跳过

3. 不明白您的意思，看报错是主键重复了。

[qhd2004]

我又重新做了一次导出与导入，然后drainer还是报错，我把drainer.log上传，请帮忙分析一下，谢谢！drainer.log (2.5 MB)

[qhd2004]

在tidb中原先是有一些库的，我drop database后，做的mydumper，但是在drainer日志中，却还有这些库、表的信息。例如：我在tidb中 drop database saas_cube_xyzphp，但是在drainer日志中有创建这个库、表的日志信息，这有些不解。

如果只同步现在tidb中现在库到下游mysql，那我要如何做呢？

本次mydumper的meda cat metadata Started dump at: 2020-06-10 10:57:31 SHOW MASTER STATUS: Log: tidb-binlog Pos: 417270163189792771 GTID:

Finished dump at: 2020-06-10 10:57:32

我怎么在下游中从Pos: 417270163189792771开始应用日志呢？

[来了老弟]

你好，

清理下游集群数据，checkpoint，根据文档再将 pos 对应 value 写入 initial_commit_ts

https://pingcap.com/docs-cn/stable/tidb-binlog/deploy-tidb-binlog/

[qhd2004]

那我把下游mysql中的tidb_binlog与tidb_loader这两个库drop掉，可以吗？

只保留mysql中自己的库：information_schema、mysql、performance_schema、sys其他的都drop掉

然后在tidb中把tidb_loader也drop掉，这样吗？

[来了老弟]

如果和导入数据源不冲突可以保留，如果 tidb_loader 没有用了可以删除

[qhd2004]

还是不行，日志中报有已经从tidb中删除的库与表的创建

[来了老弟]

drainer 启动获取 ddl job history ，上传下 drainer.log 看有木有异常把。

[qhd2004]

drainer.log (2.5 MB)

[来了老弟]

你好,

create view 指定用户不存在，先检查下，或者 mydumper 过滤掉 view ，在 tidb 中手动创建也可。

[qhd2004]

问题解决了，我是手工更新下游mysql中的checkpoint里的committs的值，然后启动drainer就可以了。

猜测的原因是：
下游mysql中的tidb_binlog库中checkpoint表里的checkpoint的值，在loader到mysql，然后启动drainer时，应该是从drainer_servers:initial-commit-ts: 的值拷贝过来的，但是现在情况是，checkpoint中拷贝过来的值是小于这个drainer配置里的，所以在drainer启动时，会按下游mysql中的tidb_binlog表里的checkpoint里的值去开始应用，这样，之前删除的库与表就会被创建出来，然后在drainer在某个应用时（那个视图或是用户时）出现问题就报错了。

[yilong (yi888long)]