redhat EL6.5下的mysql5.7并行复制原理及基本配置

原理:

一般主从复制，有三个线程参与，都是单线程：Binlog Dump（主） —–>IO Thread （从） —–> SQL Thread（从）。
但是这种复制方式会有很大的延迟,一般延迟出现在下面两个地方:
1）SQL线程忙不过来（可能需要应用数据量较大，可能和从库本身的一些操作有锁和资源的冲突；主库可以并发写，SQL线程不可以；主要原因）

2)IO延迟（次要原因）。
网络抖动,磁盘IO能力,线路带宽限制
就是说延迟主要在从机上

为了提高复制效率,mysql5.7提出了并行复制(基于组提交)
其实从MySQL从5.6开始就有了SQL Thread多个的概念，可以并发还原数据，即并行复制技术。
　　MySQL 5.6中，设置参数slave_parallel_workers = 4(>1)，即可有4个SQL Thread（coordinator线程）来进行并行复制，其状态为：Waiting for an evant from Coordinator。
但是其并行只是基于Schema的，也就是基于库的。如果数据库实例中存在多个Schema，这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形,那基于库的并发就没有卵用。

其核心思想是：不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致。

　　在MySQL 5.7中，引入了基于组提交的并行复制（Enhanced Multi-threaded Slaves），设置参数slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，即可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。

其核心思想：一个组提交的事务都是可以并行回放（配合binary log group commit）；
slave机器的relay log中 last_committed相同的事务（sequence_num不同）可以并发执行。

　其中，变量slave-parallel-type可以有两个值：
　　DATABASE 默认值，基于库的并行复制方式；
　　LOGICAL_CLOCK：基于组提交的并行复制方式

简单的讲,就是5.7之前的并行复制是基于库提交的,每个库分配一个线程,如果多个库的话,确实大大提升了复制效率,但是很多情况下都是单库多表,那么这种情况下所谓的并行复制就比较鸡肋了.

而5.7提出的并行复制是基于组提交的,就是说slave机器中的相同事物可以并发执行,意味着可以多个线程对一个库进行操作,那之前遇到的单库多表并行复制问题就得到了完美的解决,它不仅能对不同的库进行并行复制,也能对相同的库进行并行复制.

配置:

在slave主机上开启基于组提交的方式:
在主从复制的基础上,在/etc/my.cnf里添加以下几行:

slave-parallel-type=LOGICAL_CLOCK      
slave-parallel-workers=16           
#开启16个线程,可以在slave上mysql用 show processlist查看当前进程,最多显示100条,要全部显示用 show full processlist

master-info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

其他配置与主从复制一致