09-mysql主从复制实现多线程复制

主从复制原理

1. master节点上的binlogdump线程，在slave与其正常连接的情况下，将binlog发送到slave上。
2. slave节点的I/O Thread，通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。
3. slave节点的SQL Thread，该线程读取relay log日志信息，将在master节点上提交的事务在本地回放，达到与主库数据
   保持一致的目的。

MySQL5.5及以前的复制一般主从复制有三个线程且都是单线程：
Binlog Dump（主）‐> IO Thread（从）‐> SQL Thread（从）
而 master 这边是通过并发线程提交，事务通过LSN写入binlog；但是Slave只有一个IO线程和SQL线程，是单线程，所以在业务大的情况下就很容易造成主从延时。

如果在MySQL5.6版本开启并行复制功能（slave_parallel_workers > 0），那么 SQL线程就变为了 coordinator线程，coordinator线程主要负责以下两部分内容：
Coordinator+worker（多个）
若判断可以并行执行，那么选择worker线程执行事务的二进制日志。
若判断不可以并行执行，如该操作是DDL，亦或者是事务跨 schema 操作，则等待所有的worker线程执行完成之后，再 执行当前的日志。这意味着coordinator线程并不是仅将日志发送给worker线
程，自己也可以回放日志，但是所有可以并行的操作交付由worker线程完成。

上述机制实现的基于schema的并行复制，存在的问题是：
这样设计的并行复制效果并不高，如果用户实例仅有一个库，
那么就无法实现并行回放，甚至性能会比原来的单线程更差， 而单库多表是比多库多表更为常见的一种情形。

MySQL5.7 的 MTS（Enhanced Muti‐threadedslaves）
MySQL 5.7 引入了新的机制来实现并行复制，不再有基于库的并行复制限制，主要思想就是slave服务器的回放与主机 是一致的，即master服务器上是怎么并行执行，slave 上就怎样进行并行回放。
mysql v5.7.2 进行了优化，增加了参数slave_parallel_type，参数有两个选项：

LOGICAL_CLOCK：基于逻辑时钟 ，可以在一个DATABASE中并发执行relay log事务
DATABASE： 基于数据库，v5.6 默认是这个参数，该参数每
个库只能一个线程；

slave‐parallel‐type，其可以配置的值有：
DATABASE：默认值，基于库的并行复制方式
LOGICAL_CLOCK：基于组提交的并行复制方式

在从库上配置参数：

[root@mysql02 ~]# vi /etc/my.cnf
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=2   # 等于CPU核心数
master_info_repository=TABLE # 开启MTS功能后，会频繁更新master.info，设置为TABLE减小开销。
relay_log_info_repository=TABLE
relay_log_recovery=ON # （slave IO线程crash，如果relay‐log损坏，则自动放弃所有未执行的relay‐log，重新从master上 获取日志，保证relay‐log的完整性
slave_preserve_commit_order=ON # 保证提交的顺序性
log_bin=mysql‐bin # 必须开启，不然参数slave_preserve_commit_order会报错
log_slave_updates=ON