对于主从延迟，其实一直以来就是一个颇有争议的话题，在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=50 prepare
加压测试使用如下的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 run查看主从延迟，使用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 -- 逻辑时钟，主上怎么并行执行的，从上也是怎么并行回放的。所以我们开启了logical_clock.
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中的提升效果非常显著。
