MySQL5.7并发复制演进
MySQL5.5及以前的复制
一般主从复制有三个线程且都是单线程：
Binlog Dump（主） --> IO Thread（从） --> SQL Thread（从）。
1、master节点的Binlog dump Thread，当slave节点与master正常连接的时候，master把更新的binlog内容推送到slave节点。
2、slave节点的I/O Thread ，该线程通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。
3、slave节点的SQL Thread，该线程读取relay log日志信息，将在master节点上提交的事务在本地回放，达到与主库数据保持一致的目的。
一般复制出现延迟主要在两个方面：
1）SQL线程忙不过来（可能大事物操作数据量较大；可能和从库本身的一些操作有关，有锁和资源的冲突；主库可以并发写，SQL线程不可以；主要原因）
2）网络抖动导致IO线程复制延迟（次要原因）。
MySQL5.6的改进
MySQL 5.6版本引入并发复制（schema级别），基于schema级别的并发复制核心思想：“不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致”。可见MySQL5.6版本的并发复制，一个schema分配一个类似SQL线程的功能。
在上图的红色框框部分就是实现并行复制的关键所在。在MySQL 5.6版本之前，Slave服务器上有两个线程I/O线程和SQL线程。I/O线程负责接收二进制日志（更准确的说是二进制日志的event），SQL线程进行回放二进制日志。如果在MySQL 5.6版本开启并行复制功能（slave_parallel_workers > 0），那么SQL线程就变为了coordinator线程，coordinator线程主要负责以下两部分内容：
- 若判断可以并行执行，那么选择worker线程执行事务的二进制日志。
- 若判断不可以并行执行，如该操作是DDL，亦或者是事务跨schema操作，则等待所有的worker线程执行完成之后，再执行当前的日志。
这意味着coordinator线程并不是仅将日志发送给worker线程，自己也可以回放日志，但是所有可以并行的操作交付由worker线程完成。
上述机制实现的基于schema的并行复制存在的问题是这样设计的并行复制效果并不高，如果用户实例仅有一个库，那么就无法实现并行回放，甚至性能会比原来的单线程更差，而单库多表是比多库多表更为常见的一种情形。
MySQL5.7的MTS（Enhanced Muti-threadedslaves）
MySQL 5.7引入了新的机制来实现并行复制，不再有基于库的并行复制限制，主要思想就是slave服务器的回放与主机是一致的，即master服务器上是怎么并行执行，slave上就怎样进行并行回放。
为了兼容MySQL 5.6基于库的并行复制，5.7引入了新的变量slave-parallel-type，其可以配置的值有：
- DATABASE：默认值，基于库的并行复制方式（兼容MySQL5.6）
- LOGICAL_CLOCK：基于组提交的并行复制方式
当slave配置slave_parallel_workers(=8)>0并且global.slave_parallel_type='LOGICAL_CLOCK' 时，可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。但是要实现以上功能，需要在master机器标记binary log中提交的事务哪些事物是可以并发执行，MySQL5.7将组提交的信息存放在GTID中。
那么如果用户没有开启GTID功能，即将参数gtid_mode设置为OFF呢？
故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型，如：
在MySQL 5.7的master机器上，用命令 mysqlbinlog mysql-bin.0000006| grep last_committed 可以看到last_committed和sequence_number，last_committed和sequence_number代表的就是LOGICAL_CLOCK。
server id 15102 end_log_pos14623 CRC32 0x767a33fa GTID last_committed=18 sequence_number=26server id 15102 end_log_pos15199 CRC32 0x7dd1bf05 GTID last_committed=26 sequence_number=27server id 15102 end_log_pos15773 CRC32 0xb01dc76e GTID last_committed=26 sequence_number=28server id 15102 end_log_pos16347 CRC32 0x7a8e0ee8 GTID last_committed=26 sequence_number=29server id 15102 end_log_pos16921 CRC32 0x92516d17 GTID last_committed=26 sequence_number=30server id 15102 end_log_pos17495 CRC32 0xeb14a51e GTID last_committed=26 sequence_number=31server id 15102 end_log_pos18071 CRC32 0x750667d0 GTID last_committed=26 sequence_number=32server id 15102 end_log_pos18645 CRC32 0xcaed6159 GTID last_committed=26 sequence_number=33server id 15102 end_log_pos19219 CRC32 0x62408408 GTID last_committed=26 sequence_number=34server id 15102 end_log_pos19793 CRC32 0x5cf46239 GTID last_committed=33 sequence_number=35 |
|---|
在slave机器的relay log中 last_committed相同的事务（sequence_num不同）可以并发执行。一个组提交的事务（group commit）都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，说明事务之间没有任何冲突（否则就不可能提交）。
从上面截取的信息可以看出last_committed=26的事务一共有8个：从sequence_number=27-34，假设当slave_parallel_workers=8时，Coordinator线程分配这一组事务到worker中排队去执行。
增加master库binary log group commit组中事务的数量可以提高slave机器并发处理事务的数量，MySQL5.7引入 binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count参数来提高binary log组提交并发数量。
MySQL等待binlog_group_commit_sync_delay毫秒的时间直到binlog_group_commit_sync_no_delay_count个事务数时，将进行一次组提交。
MTS配置
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE （开启MTS功能后，会频繁更新master.info，设置为TABLE减小开销）
relay_log_info_repository=TABLE （开启MTS功能，要求必须置为TABLE）
relay_log_recovery=ON （slave IO线程crash，如果relay-log损坏，则自动放弃所有未执行的relay-log，重新从master上获取日志，保证relay-log的完整性）
slave_preserve_commit_order=1 （保证提交的顺序性）