如何进行MySQL并行复制测试

关于主从延迟，一直是一个有争议的话题。在MySQL阵营中，如果可以容忍一定的延迟场景，通过主从实现读写分离是一个非常好的解决方案，但是延迟率能接受多高呢？新版本并行复制的效果如何？不同版本有什么变化吗？我们能找到一些参考数据来支持这一点吗？我们可以用一些小测试来说明这一点。 。

首先，为了基本遵循相同的参考标准，我们在同一台服务器上安装了5.6和5.7的MySQL服务，并在另一台服务器上搭建了从库。

数据库版本为5.6.23 Percona分支，5.7.17 MySQL官方版本

服务器上安装了pt工具来检测主从延迟，安装了新版本的sysbench来做这个压力测试。

主库：10.127.128.227 RHEL6U3 32G R710
从库：10.127.128.78 RHEL6U3 32G R710 为了基本达到相同的基准进行测试，我先启动了5.6数据库服务，测试完成，启动5.7服务。避免多个实例的并行干扰。

初始化数据使用类似于下面的脚本，在5.6和5.7版本中类似。

创建了10张表，插入了500万条数据进行测试。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3308 --mysql-socket=/home/mysql_5 .7.17/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=50prepare

压力测试使用遵循 sysbench 脚本，持续 300 秒 sysbench /home/sysbench/sysbench-1.0.3 /src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3308 --mysql-socket=/home/mysql_5.7.17/mysql.sock --mysql-host=localhost - -mysql-db =sysbenchtest --tables=10 --table-size=5000000 --threads=50 --report-interval=5 --time=300 运行检查主从延迟，使用pt-heartbeat完成。

启动后台任务：

pt-heartbeat h='10.127.128.78',u='pt_checksum',p='pt_checksum',P=3307 -D sysbenchtest --create -table --interval=1 --update --replace --daemonize 启用主从延迟检测：

pt-heartbeat h='10.127.128.78',u='pt_checksum',p=' pt_checksum ',P=3308 -D sysbenchtest --table=heartbeat --monitor --master-server-id=3308 --frames=5s --interval=5
因为5.6中是主从复制，所以在5.7中仍然存在，我们将分别测试单线程和多线程复制之间的差异和改进。

并行复制的基本配置

5.6开启并行复制

mysql>stop slave;
mysql>set global Slave_parallel_workers=8 ;
mysql>start Slave;

5.7开启并行复制

值得一提的是，5.7已经做了一些改进，slave-parallel-type= DATABASE /LOGICAL_CLOCK
-- DATABASE -- 基于库级别的并行复制与5.6相同
-- LOGICAL_CLOCK -- 逻​​辑时钟，master如何执行并行，以及从设备如何并行播放它。所以我们启用了逻辑时钟。

mysql> stop Slave;
mysql> set global Slave_parallel_type='LOGICAL_CLOCK';
mysql> set global Slave_parallel_workers=8;
mysql> stop Slave;

并行复制效果对比图

下面是得到的概览图。横轴是测试时间，纵轴是延迟时间。

总体来说，MySQL 5.6中并行复制效率的提升还不够显着，而5.7中的提升效果却非常显着。

看完以上内容，您对如何进行MySQL并行复制测试有进一步的了解吗？如果您想了解更多知识或相关内容，请关注行业资讯频道，感谢您的支持。