今天在测试dm数据同步的时候发现个问题,tidb的压测性能很高,但实际上跟不上mysql的写入操作,测试过程如下:
1、使用dm工具打通tidb与mysql的数据同步
2、使用sysbench在测试库中创建表,执行语句如下:
sysbench --config-file=config oltp_point_select --tables=30 --table-size=100000 prepare
3、然后tidb就同步延迟了,这个prepare操作在mysql中大约执行了10s,tidb现在已经同步了10分钟以上,但还是有很多数据没有同步过来,监控中发现commit量非常少,这个为什么这么少呢
请问问题出现在哪
这个是执行prepare时mysql的监控,大概commit了1500次,tps在20以下,在这种写入情况下tidb依然延迟很重有点出人意料
qizheng
(qizheng)
3
您好,10分钟看起来不太正常,麻烦上传下 tidb 和 tikv 的监控
task.yaml设置的单线程备份:
syncers:
global:
worker-count: 1
batch: 100
监控显示每个sql执行时间在125ms左右,这个速度很快了,但数据却没写进去,这个很奇怪
qizheng
(qizheng)
6
该图是mysql ----> dm -----> mysql的同步效果:
通过dm同步数据到tidb现在的情况是同步非常慢,针对dm、tidb我们做了如下测试:
1、对tidb节点进行压力测试,tps>8000,排除因tidb性能导致的sql执行慢
2、dm开启32线程向tidb同步数据,同步延迟严重(上游mysql的tps<50),怀疑瓶颈在dm工具上
3、使用dm工具(开启4线程)进行如下同步mysql ----> dm -----> mysql,同步没有延迟,(上游mysql的tps>5000),至此dm工具同步似乎也没问题
那么问题出在哪呢
qizheng
(qizheng)
9
query status 看到 sync binlog 有同步延迟,可能是 checkpoint 表里记录的点位没有及时刷新,目前在有 dml 的情况下默认超过 30s 才更新,实际同步的位置可能已经是最新了
如果希望准确监控同步延迟,建议开启 heartbeat,通过
curl curl dm-worker-ip:port/metrics
抓取 replicate lag(master 到 syncer 的 binlog 复制延迟时间(秒)),查询表达式
dm_syncer_replication_lag{task=“$task”, instance=“$instance”}