DM load 慢

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

你好,

请上传下 tidb.log 文件,可能是执行 sql 时,出现问题。

可以自行将 sql_mode 设置为 ‘’ ,看是否能解决。

tidb在今天11:40多重启后,这是重启后的日志。一会试一下sql_mode tidb.log (25.8 KB)

这个sql_mode设置为空,会不会影响0000-00-00 00:00:00这种日常的插入啊?
已经将sql_mode置为空了。看看效果,不行再改回去。
已经试过,将其置为空,重新stop-task、start-task后,问题已经存在

你好,

查看 dm-worker.log 其中存在大量的表已创建的报错,建议

  1. stop-task
  2. 清空下游同步数据
  3. start-task

现在已经完成了38.37%,清空数据是指将,现在数据库当中所有的表中数据都清理掉?还是将所有表都drop掉?这个同步任务涉及7个数据库。

你好,

请问当前 mydumper 出来的数据大概多大?

  1. tidb.log 中存在 ‘Region is unavailable’,可以看下 tikv 的状态是否太过繁忙,可以上传下监控中 overview - tikv 面板

  2. 从 query-status 和 dm-woker.log 看,存在 ddl 冲突,频繁的重试增大了 tidb 的压力,也是有可能的。

确认以上问题后,这边可以看接下来怎么做好些

原来7个库mydumper数据32G,现在已经将这个任务清理掉,直接分成七个任务,一个任务一个库,但还是有问题。

你好,

通过监控,看到目前集群 leader 出现大量迁移,请执行并返回下结果,确认下 118 的 leader_score 与其他节点是否有很大差异

./tidb-v4.0.0-rc-linux-amd64/bin/pd-ctl -u http://172.16.5.169:22379 store

[tidb@kaikaitidb1 bin]$ ./pd-ctl -u http://10.7.110.114:2379 store { “count”: 3, “stores”: [ { “store”: { “id”: 1, “address”: “10.7.110.117:20160”, “version”: “3.0.5”, “state_name”: “Up” }, “status”: { “capacity”: “787.3GiB”, “available”: “708.1GiB”, “leader_count”: 359166, “leader_weight”: 1, “leader_score”: 441621, “leader_size”: 441621, “region_count”: 375090, “region_weight”: 1, “region_score”: 461278, “region_size”: 461278, “start_ts”: “2020-05-13T08:59:19+08:00”, “last_heartbeat_ts”: “2020-05-13T09:17:05.366187782+08:00”, “uptime”: “17m46.366187782s” } }, { “store”: { “id”: 4, “address”: “10.7.110.119:20160”, “version”: “3.0.5”, “state_name”: “Up” }, “status”: { “capacity”: “787.3GiB”, “available”: “710.4GiB”, “leader_count”: 11861, “leader_weight”: 1, “leader_score”: 14020, “leader_size”: 14020, “region_count”: 377530, “region_weight”: 1, “region_score”: 458212, “region_size”: 458212, “receiving_snap_count”: 1, “start_ts”: “2020-05-13T09:14:59+08:00”, “last_heartbeat_ts”: “2020-05-13T09:17:02.357081996+08:00”, “uptime”: “2m3.357081996s” } }, { “store”: { “id”: 5, “address”: “10.7.110.118:20160”, “version”: “3.0.5”, “state_name”: “Up” }, “status”: { “capacity”: “787.3GiB”, “available”: “713.6GiB”, “leader_count”: 190350, “leader_weight”: 1, “leader_score”: 234804, “leader_size”: 234804, “region_count”: 370138, “region_weight”: 1, “region_score”: 461404, “region_size”: 461404, “start_ts”: “2020-05-13T09:06:04+08:00”, “last_heartbeat_ts”: “2020-05-13T09:16:57.427564841+08:00”, “uptime”: “10m53.427564841s” } } ] }

你好,

  1. 烦请提供下监控中 pd - 界面和 cluster 监控项的内容,当前怀疑 store 已用空间和 leader 数量相差较多,帮忙加以印证。
  2. 请上传下三台 log/tikv.log,这边看下 tikv 这边存在的问题

grafana监控界面在截图时,工具不好用,都保存到excel里面了。三个tivk的日志也上传了。 tikv_117.log (4.1 MB) tikv_118.log (3.5 MB) tikv_119.log (4.1 MB) grafana界面指标.xlsx (3.1 MB)

你好,

根据 overview 中 region health 显示 empty-region-count 为 559k,在数据占用仅为 80G 上下的 集群来说已经很多了。请根据以下链接开启 region merge 看是否可缓解 tikv 繁忙的问题。

已经开启了region merge。TiDB集群中TiDB服务器总是重启,rongyilong同事帮忙解决的,在解决时开启了这个。
image

你好

ok,开启之后看来还没合并

  1. 可能还没有达到合并阈值,需要调小

  2. 还有可能之前做过 drop 或者 truncate table 操作,导致有很多空表,目前默认情况,空表的region 是不自动合并的需要增加以下两个参数。(你可以先调整这两个参数,看效果不行就调小 region size 的阈值)

  3. PD 参数 namespace-classifier = “default”

  4. TiKV 参数 split-region-on-table: false

可以在中控节点修改 pd.yml 然后执行 ansible-playbook rolling_update.yml --tags=pd 来使修改生效或者 edit-config 之后通过 tiup cluster cluster-name reload -R pd。

麻烦反馈下一下信息和展示信息

将下图信息展示下:

修改配置:(通过ansible-playbook rolling_update.yml --tags=pd ansible-playbook rolling_update.yml -t tikv 这两个命令重启的)
image image
上面命令没有执行时的数量:

按照上面的配置修改成功。
image

image

好的,请问目前 empty-region-count 是否有所下降?

麻烦反馈下下面这个图,看下 current storage size。

刚才一直观察当中,current storage size有下降,但number of regions没有下降。之后又按修改了一下配置,如下图,也没起作用: image


上次的截图

region数量开始减少了,但速度不是很快30秒少了80个左右