- 【TiDB 版本】：docker-compose自动拉取的，应该时最新；DM是1.0.4
- 【问题描述】：为了调研TIDB，我先用docker-compose搭建了一个环境，然后用DM1.0.4同步我们生产库的一个库到tidb,大表大概2000多万，在生产环境种，数据在变动。可是我同步到TIDB后只有1000多万，后台dmwork日志我上传了，麻烦看一下，task任务最简单的，就是同步一个库。
dmworker.log (1.7 MB)
好的
正在分析，请稍等
能看出是什么问题吗？因为我自建表，自己插数据的确是正常的，但是遇上这种大数据量，还实时有业务的，就会出问题，如果我上生产到时数据应该至少5个亿，这种能实时同步吗？
你好，
根据日志分析，存在很多主键冲突和插入报错情况，下游 insert 也出现 connection cancel 报错。
请配合：
1，提供下task任务配置文件
2，提供下 overview - system info 下的监控内容
3，dmesg -T | grep -i oom 查看 tidb 是否存在 oom。或者 more log/tidb.log |grep Welcome 查看 tidb 在导入期间是否出现重启
如果是线上配置请按照官网要求准备硬件
对于生产环境，不要使用 Docker 进行部署，而应使用 TiUP 部署 TiDB 集群。
您好：
监控内容和tidb的log日志我上传了，另外查了oom并没有，因为我的配置也不低
tidb有部分ERROR，最后几条可以看一下。
我试过几个库了甚至是200万数据的表也是有connection cancel
生产环境肯定是不用docker的，目前只是测试，生产环境会同步18亿数据
tidb.log (64.6 KB)
你好，
麻烦请将 overview 全部都截图下来，上传下，多谢
截全屏办法：
(1)、chrome 安装这个插件 https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按？可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
你好，
我们看下
你好，
- 根据 tidb 中的报错，请检查下 pd 的状态
- 问下目前集群拓扑，可能由于 IO 争用，当 TiKV 负载很高时，PD 可能有问题。最好使用其他主机，或将 PD 放在单独的磁盘上（不需要达到最佳性能，但最好与 tikv 隔离）。
好的，感谢回复
如果硬件有限可以尝试调整各阶段的并发度来适应系统
目前看还是建议使用 tiup 测试部署 4.0.0-rc，目前该版本测试比较火热，asktug 有很多相关的问题。
如有问题，可开新帖继续讨论。
你好，上面 DM 导入后少了很多数据的问题，看 DM log 是全量导入过程中，下游资源不够抗不住，导致 DM 同步中断。所以后面还有很多数据没有继续导入。
建议：
- 清理下游导入过的数据（DROP 对应的库、表）
- 清理下游 DM 生成的断点 checkpoint 表（在
dm_meta库中） - 重新导数据（由于下游资源不够，建议给 loaders 调小并发，比如 4）
1 个赞
各位好：接上周的问题继续咨询
上周我测试导入数据，有一个库的一个表2000万数据的当时数据导入少了一半，有一个库300万表数据导入多出了问题，经过上周分析是可能资源不够导致的，上周的环境是docker-compose单机拉的；
本周，今天我重新搭建了环境，用tiup搭建的，总共4台主机，三个tikv和pd公用，tidb一台，目前在测试300万数据导入，现在日志里已经出现了上周报得错，数据还没结束，结束了在看，错误如下：
我觉得此问题不是资源问题，因为这个MySQL 连接问题后台日志重复了好几次mysqldumper，每次一报错后就进行一次，我这次的配置不高但是也勉强可以了，都是物理服务器，16G内存，
你好，
可以将 task 文件完整上传一下看一眼，根据官网建议硬件配置，目前看还是配置低了些，但是可以通过调整上面的参数来实现测试的目的，降低并发数和 batch 是目前比较好的方法，
task在上面回复种有，已经是完整的了，至于dm-work的日志，等结束了我会传一遍的，另外这个数据我说错了是800万，
你好，
上面只有任务相关，不知道，mydumper loader syncer 是否有配置，这些是导入速率相关的
可以的，可以等导入验证完毕一起回复。
