LOGICAL_CLOCK:基于组提交的并行复制方式
mysql>show variables like "slave_parallel_type"
mysql>show variables like "slave_parallel_workers"
master_info_repository=TABLE #开启MTS 功能后,会频繁更新master.info,设置为TABLE 减小开销
slave_master_info 记录了首次同步master 的位置relay_log_recovery=ON (slave IO 线程crash,如果relay‐log损坏,则自动放弃所有未执行的relay‐log,重新从master 上获取日志,保证relay‐log 的完整性)
slave_preserve_commit_order=ON 在slave 上应用事务的顺序是无序的,和relay log 中记录的事务顺序不一样,这样数据一致性是无法保证的,为了保证事务是按照relay log 中记录的顺序来回放,就需要开启参数slave_preserve_commit_order。
虽然mysql5.7 添加MTS 后,虽然slave 可以并行应用relay log,但commit 部分仍然是顺序提交,其中可能会有等待的情况。
测试mysql5.7和mysql8.0 分别在读写、只读、只写模式下不同并发时的性能(tps,qps)
机器
myql5.7.22
mysql8.0.15
sysbench
mysql5.7和mysql8.0 在读写模式下的表现
双1 配置,读写模式下,mysql5.7.22 和mysql8.0.15 tps 、qps 性能差不多,mysql8.0.15 在120 线程并发时,性能出现了下降抖动:
mysql5.7和mysql8.0 在只读模式下的表现
双1 配置,只读模式下,mysql5.7.22 的tps、qps比mysql8.0.15 好1/3 左右;并发线程数增加后,tps、qps并没有随着增加,反而出现了下降的趋势:
mysql5.7和mysql8.0 在只写模式下的表现
双1 配置,只写模式下,随着并发数的上升,mysql5.7.22 的性能比mysql8.0.15 好1/4左右
mysql5.7和mysql8.0 在读写模式下的表现
0 2配置,读写模式下,并发数低时,mysql5.7.22性能好于mysql8.0.15并发数比较高时,mysql8.0.15 性能好于mysql5.7.22;在80 线程的并发以上时,性能开始下降
mysql5.7和mysql8.0 在只读模式下的表现
0 2配置,只读模式下,mysql5.7.22性能比mysql8.0.15 好1/3左右;随着并发数的上升,性能也没有上升,反而有下降的趋势
mysql5.7和mysql8.0 在只写模式下的表现
注意
sysbench 需要设置--db-ps-mode=disable 禁用预编译语句,不然并发测试线程多时会报下面的错误
使用脚本
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)