将阿里云的tidb数据同步到本地tidb

Mydumper 可以通过 -r 或者 -F 来对一个表进行并发的备份并且会生成多个 .sql 文件。具体可以看看 Mydumper 的官方文档。

导入的数据也不多,才几十万,就一直这样,数据少的就直接导进去了,这是什么原因。 loader语句:./bin/loader -h 192.168.141.10 -u root -p ‘879445’ -P 4000 -t 32 -d ./value

  1. 可以看下下游 TiDB 集群监控,看下集群负载高不高

  2. 查看下游 tidb.log 日志,确认 tidb server 正常工作

  3. 可以检查一下 loader 所在服务器 CPU 使用情况

  4. 因为日志打印的是 loader 的进度,请问 progress 是否会改变,还是 loader 一启动就是 1.67%,然后一直卡住不动

  5. 可以尝试将减少并发 -t 设置为 4 看是否可以导入

一启动就是1.67,很多时候是0.00,导3000条数据很快,导几十万就不行了,试了好几次都是这样,而且tidb卡住了,数据库也打不开,就跟死机了一样

可能是 tidb 负载太高

  1. 方便的话提供一下 tidb.log 日志
  2. 可以降低并发,调整 -t 为4 ,降低 tidb 的压力看下数据能否导入,不卡住 tidb

这是日志,我是在自己电脑的虚拟机运行的,测试用,到时候我们线上有30亿数据,会不会直接挂掉

从日志看是 tidb 连接 tikv 时没有响应,判断是并发写入量大导致 tikv 繁忙

  1. 可以 grep -i welcome tikv.log 确认一下 tikv 是否有重启的情况
  2. 可以降低并发,调整 -t 为4 ,降低 tidb 的压力看下数据能否导入,不卡住 tidb
  3. 线上环境导入数据,主要看服务器配置,如果服务器配置足够,那导入一般不会有问题

好的,谢谢啊,我自己的电脑配置不是很高,所以很卡,我一会修改并发试一下,有问题我及时请教

嗯嗯,有问题可以反馈给我们:rose:

换成4也不行,直接卡死机,退都退不出来,只能重启虚拟机,

这个是tikv的日志,导数据的那会没有这条日志

loader 也是运行在自己虚拟中的么,因为 loader 要执行并发导入的话,会要去解析 sql 文件,这个步骤会比较占用 CPU。

你这边部署本地 TiDB 用的拓扑以及机器配置是怎么样的?

机器配置不咋滴,是不是loader最好重新运行一台虚拟机比较好

嗯,可以考虑新开一台虚拟机运行 loader,排除 loader 对集群负载的影响

我想请教下,用mydumper将数据库的表和库以及数据备份到一个文件夹下,loader导入的那边这个库表已经存在了,但是是个空表,他会报一个库已存在,就不往下执行了,能不能在库表存在的情况下,直接往里面插入数据,跳过创建库和创建表的这个步骤呢

当前 loader 导入时确实时需要检查建库或者建表语句,可以手动更改为create table if not exist 或者 load data 是否能够满足需求?

mydumper备份30亿数据中的4亿数据报 GC life time is shorter than transaction duration, transaction starts at 2020-04-02 我看网上解决方案是update mysql.tidb set variable_value=‘30m’ where variable_name=‘tikv_gc_life_time’; 这样会对我们现在的生产库以及现在生产库的数据有影响吗

您好: 会有一些影响,参考下https://pingcap.com/docs-cn/stable/reference/garbage-collection/configuration/

那我在执行mydumper执行完成后将这个参数在改回来,这样的话就没什么问题了吧, 另外数据会不会丢失以及新增的数据会不会进来,这些有没有影响,我主要就是备份一部分数据。就怕对现在生产库造成影响,那麻烦就大了

  1. 改回来之后,可能下一次gc的数据量比较大,一般没有什么影响.
  2. 如果担心对生产有影响,建议在业务低峰期进行.