start slave;
图中使用了2个主库：music和habit，假设music存放音乐的歌手、名称和其他信息，habit保存了用户的偶像、最喜欢的歌、常听的歌、播放高峰时间段和地理位置信息的话，汇聚到从库便可即实现了经济实惠的从库端分库合并又实现了统一做用户行为分析，还可以用一条mysqldump命令加个--all-databases参数全部导出做备份。
考虑到多源复制运行过程中，一台从库要接受多方的数据，相比压力会比单库复制有所提升，因此需要优化一下从库配置，从而提升从库执行效率。
性能提升利器——并行复制
接下来要说的就是：性能提升利器——并行复制。 为了提高SQL线程(SQL thread)的执行效率，减少主库与从库之间的延迟，MySQL提供了并行复制的特性，可以将事务在从库上多线程并发的回放应用，从而达到加速同步速度的效果。
需要注意的是，使用过程中还是有一些问题需要稍加留意，如果设置不当，反而可能会画蛇添足。
就拿性能来说，并不是并发开的越高越好，并发开的过高和过低，都可能带来负面性能影响，比如引起Coordinator的判断、分发等处理过程开销升高，使用Sysbench进行压力测试的过程中，该开销升高症状体现在CPU消耗高。可能在不同的环境和业务场景下都会有相应的反应，需要量体裁衣、因地制宜。
下图为1主1从SQL线程并行复制回放过程：
图2中，SQL线程(SQL thread)由原来的1个，分裂变成了1个Coordinator和N个worker。Coordinator主要用来分发工作给不同的worker，并且在必要时自己也进行重演操作。图中分了18个并行，即18个worker并行工作。他们负责并行的将日志中可以划分成一组的事务进行并行回放。
在把事务应用到从库的时候，根据binary log中last_committed(需设置并行类型为logical clock)的值判断是否可以放在一组进行并行回放，如果取值相同，便并行执行。
日志信息：
从日志中看到，数据库已经开启了GTID(全局事务标识)功能，此功能是5.6版本出现的，可以保证每个提交的事务都会有一个全局唯一的编号，日志中也可看到GTID信息。
多源复制开启并发后的架构图：
开启并行复制操作的方法对于1主和多源是一样的：
stop slave;
SET GLOBAL SLAVE_PARALLEL_TYPE='LOGICAL_CLOCK';
SET GLOBAL SLAVE_PARALLEL_WORKERS=30;
start slave;
验证配置生效：
用show processlist命令会看到会出现多个coordinator线程和每个co线程所分配的30个worker线程，总共60多个线程。(由于worker阵容太庞大，超占篇幅，就不在此展示了)
为什么选择并行度为30，原因是从1主1从的测试中发现该并行度在本次测试环境中磁盘资源利用率略高于其他场景，CPU消耗相对比较低，内存消耗差别不大，总体效率最高，执行时间最短。
1 主1从复制时Slave数据库的CPU性能状态特征：
CPU 性能统计：
从图中可以看到，在本次测试环境中，CPU状态最好的是并发度为18和30的时候，并发度为300的时候CPU反而消耗明显;并发为2的时候cpu消耗高，并且处理时间更耗时;并发为0的时候，其实等于不并发，CPU利用率不高，耗时也较长;值得关注的是，并发度设置为1的时候，即使只有1个worker，但是毕竟是并发模式，此时同样在消耗coordinator的资源，并且此时coordinator也参与了重演操作，相当于2个线程进行重演，因此与并发度设置为2很接近，所以务必注意如果想关闭并发一定要设置为0，而不是1。
接下来进行多源复制的压力测试与性能监控：