MySQL主从复制性能测试

卸甲归田

影响MySQL复制性能的因素很多,网上有很多相关的介绍文章,为了更直观的了解这些因素对性能的影响,还是要自己动手做一些测试。

对于MySQL的主从复制,我们知道主要有2种,一种是异步复制,一种是半同步(semisync)复制,对于异步复制,我们测试关注的是,不同配置,对slave端,applier效率的影响,也就是说,关注的是如何尽量缩小主库和从库之间的gap,而对于半同步复制,因为其实现机制的原因,会导致主库的性能受影响,所以,针对半同步复制,我们除了关注slave端applier的效率之外,还关注主库的性能到底会降低多少。

测试环境配置

Master

Slave

OS

RHEL 7.4

RHEL 7.4

MySQL

8.0.13

8.0.13

存储

3.2T PCIe 闪存卡

3.2T PCIe闪存卡

测试工具

Sysbench,我们只测试insert语句,除主键外,不建索引。

创建表:

测试语句:

每次测试完,进行下一个测试之前,会cleanup所有表,重建。保证索引对insert的影响是一样的。

测试过程和结果

测试通用参数

Master端:

Slave端:

Durable和non-durable设置

Durable ,我没找到合适的中文词,它的意思就是为了防止crash后丢数据的参数设置:

这两个参数,一个控制是否同步写binlog,一个控制是否每次提交写innodb log,都设置成1,可以保证最大的一致性,但是也带来性能的损耗。在主库,一般都是建议设置成1的,但是在从库,可以设置成其他值,来提升applier的效率。

Non-durable就是指上述两个参数设置成非1值,我们的测试里都设置成0。

对比两个参数都设成1和设成0的结果。

在主库先通过sysbench执行120秒插入操作,然后在从库start slave,记录slave活动时间,计算slave applier效率。

单线程和多线程applier

早期的多线程applier只能对多个库的事务进行并行处理,从5.7以后,在单库中的事务也可以并行处理。相关的参数:

比较单线程(1个worker),6个和12个worker的差异:

MySQL 8.0 并行复制中的writeset

“MySQL 8.0 中引入参数 binlog_transaction_depandency_tracking 用于控制如何决定事务的依赖关系。该值有三个选项:默认的 COMMIT_ORDER 表示继续使用5.7中的基于组提交的方式决定事务的依赖关系;WRITESET 表示使用写集合来决定事务的依赖关系;还有一个选项 WRITESET_SESSION 表示使用 WriteSet 来决定事务的依赖关系,但是同一个Session内的事务不会有相同的 last_committed 值。”

使用WRITESET需要设置:

我们前面测试的并行复制,因为没有设置binlog_transaction_depandency_tracking,所以是使用缺省值,下面我们对比一下使用COMMIT_ORDER和WRITESET的区别(都是durable)

不同worker在使用WRITESET时的表现:

半同步复制

在半同步复制中,可以通过参数rpl_semi_sync_master_wait_point 控制主库是否等待从库返回ACK,再提交事务。

如果取值是AFTER_COMMIT,那么master写数据到binlog且sync,且commit,然后一直等待slave ACK。当至少一个slave request bilog后写入到relay-log并flush disk,就返回ack(不需要回放完日志)。然后master返回客户端。

如果取值是AFTER_SYNC,master写数据到binlog且sync,然后一直等待slave ACK. 当至少一个slave request bilog后写入到relay-log并flush disk,返回ack(不需要回放完日志),master得到ack,提交,返回客户端。因为AFTER_SYNC方式的半同步复制不会丢数据,不会产生”幻读”,所以又叫lossless复制。

半同步复制因为要等待slave的ack,会阻塞master的session,所以对性能是有负面影响的。

实测lossless复制和异步复制的master性能差异,同时比较不同网络(1Gb和10Gb)网络上是否有差异。

从结果看,增加网络带宽并不能明显提升master的性能。

未经允许不得转载:Oracle一体机用户组 » MySQL主从复制性能测试

相关推荐