昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试，当然只是一个开始，因为里面还有不少需要完善的部分，总体的感觉来看MySQL 5.7里的并行复制改进很大，能够极大提高效率，充分利用资源。

那我们来简单回顾一下MySQL的复制里的一些事情，然后继续展开测试。

首先借丁奇大师总结的一个经典的主从复制的流程图来展开。

整个复制的流程中，看似存在多个节点会存在延迟的可能，而如果把这些工作都细化，那么就会有一个很本质的原因，那就是在主库端的更新是多线程，而从库端更新是单线程。

这样一个看似“存在即合理”方案在MySQL 5.6以前都是这么做的。最早的复制和statement格式做斗争，过了改进，有了row格式，也算是复制方向上的一大改进，而在MySQL 5.6中引入了并行复制，这一点能够缓和原本的复制瓶颈。

但是复制的效率提升不是严格意义上质的飞跃，算是一个开篇，因为支持的是数据库级别的，如果直接多线程是否可以，这个按理说是一个很常规的思路，为什么MySQL迟迟没有推出好的方案来。

多线程存在一些待解决的难题，其中之一就是语句的顺序无法保证，无论如何，日志都是需要顺序写，在源端是多线程并发操作，而映射到日志中，必然是一个顺序的记录方式，而这个操作到了从库，也只能老老实实的按照顺序来应用，如果采用多线程就得尤其注意这个顺序，我们可以逐步来细分，首先对于同一个表的更新只能按照顺序来同步，而这个粒度可以逐步细分，比如数据库级，表级等，目前MySQL 5.6中是按照数据库级来做的，当然这个粒度还是有些粗。在5.7就全面改进了。

当然我们在开始具体的测试之前，我简单说一下我们量血压的场景，一般都会有一个收缩压，舒张压的指标，对于主从复制而言，我突然想到了这一点，我觉得还是有可以借鉴的地方。

比如我昨天测试的而一个图，是MySQL 5,6,5.7单线程，多线程的延迟对比图。

其实这个图我感觉没有画完，因为大批量的事务并发处理，必然会导致延迟，比如有10分钟的高强度并发，那么10分钟后延迟不是立即消失的，从库得慢慢消化这个延迟的数据，这个时间我们也需要关注，至于主从一致后的延迟回落到底是什么样，我想只是看这个图可能还看不出个所以然，所以想到了这一点，我就继续补充了一下测试的场景，调整了时间。

下面这个图花了我不少的时间去收集数据，整理。

中间红色的箭头就是在指定的时间范围的加压测试，而右边的部分则是延迟回落的一个过程，可以很清晰的看到，对于从库的延迟在加压完成后，延迟依旧会逐步增长，达到一个峰值后，迅速回落，回落的过程来看，MySQL 5.6中的单线程，多线程，和MySQL 5.7中的测试情况大体相似，从耗时情况和延迟回落的趋势，基本都是相似的，而MySQL 5.7的并行复制相比而言就是一个亮点，数据加压后的延迟回落极快，整个过程耗时要低很多。

当然这个图例也反映出来一些问题，那就是MySQL 5.6的单线程和多线程的结果几乎一样，这就对了，这就错了。对了是由此可以看出在这个测试场景中，并行复制没有派上用场，错了的原因是测试的场景还可以继续改进，可以更有针对性。

怎么改进呢，因为5.6中是数据库级的复制，所以我们可以建立多个数据库，然后在从库开启并行复制来改进，对比测试。

怎么能够快速看到一个效果呢。

我们继续开启sysbench的加压测试，使用pt工具同步检测延迟，花几分钟就可以看出差别来，比如我们首先建立4个数据库，每个数据库下创建10个表。

mysqladmin create sysbenchtest1初始化一部分数据，对于sysbenchtest1如此，其它的几个数据库也是类似的操作。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30 prepare然后开启sysbench测试。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30  --time=300 run查看延迟的情况：

pt-heartbeat h='10.127.128.78',u='pt_checksum',p='pt_checksum',P=3307 -D sysbenchtest --table=heartbeat --monitor --master-server-id=3307 --frames=5s --interval=5几个简单的对比就可以说明。

开启并行复制模式时，延迟如下：

0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]然后修改参数slave_parallel_workers为0，切换回单线程模式，延迟开始加大。

1.00s [  0.20s ]
0.00s [  0.20s ]
2.00s [  0.60s ]
0.00s [  0.60s ]
1.00s [  0.80s ]
0.00s [  0.60s ]
0.00s [  0.60s ]
0.00s [  0.20s ]
0.00s [  0.20s ]
1.00s [  0.20s ]再次切换回并行复制模式，延迟逐渐减低，并回复平稳。

0.00s [  0.40s ]
0.00s [  0.20s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.00s ]
0.01s [  0.00s ]
0.00s [  0.00s ]
0.00s [  0.20s ]
0.00s [  0.20s ]当然想看到更加细致的图形对比，也不是一件难的事情，得容我花点时间收集下数据，给出一个详细的对比报告。