MySQL并行复制配置与调优的操作
本篇文章给大家主要讲的是关于MySQL并行复制配置与调优的操作的内容，感兴趣的话就一起来看看这篇文章吧，相信看完MySQL并行复制配置与调优的操作对大家多少有点参考价值吧。
并行复制产生的背景：
因为I/O thread和SQL thread是单线程工作的，而Master是可以多线程写入的，所以主从难免造成延迟
基于此，在5.6，5.7，8.0版本都在SQL线程上实现了多线程，来提升slave的并发度
为什么不是I/O多线程？
I/O没必要多线程，因为I/O线程并不是瓶颈啊 （没怎么理解）
并行复制的目的：
让Slave SQL线程尽可能以多线程工作，解决复制延迟的问题
并行复制实现的前提：
能够进行并行复制，关键在于多事务之间是否有锁冲突
MySQL5.6基于schema的并行复制：
应用场景：
比较适用于一个库中有多个schema的场景
并行复制的原理：
MySQL5.6开启并行复制功能后，SQL线程变成coordinator线程，由其判断是否可以并发执行，这意味着一个worker线程可以处理一个数据库的连续事务，而不用等待其它数据库完成
如果可以并行执行，选择worker线程执行二进制日志
如果不可以并行执行，如：DDL或者跨schema操作，则等待所有的worker线程执行完成之后再执行当前日志
摘自网上的一张图片，供参考理解：
基于schema的并行复制带来的问题：
因为MySQL5.6并行复制只是基于schema，但对于单库多表的复制场景是无法实现的，甚至性能可能还达不到原来的单线程复制，而在实际工作中单库多表比多库多表的场景更为常见。
MySQL5.6基于schema级别的并发复制可以解决业务表放在不同的DATABASE下同步延迟的问题，但是在实际生产中大部分表还是放在同一个库中的，这种情况即使设置slave_parallel_workers大于0，也无法进行并发。在高并发的情况下，依然会造成主从复制延迟
MySQL5.6并行复制开启：（前提是配置好主从复制环境）
mysql> stop slave;
Query OK, 0 rows affected (0.03 sec)
mysql> set global slave_parallel_workers=8;
Query OK, 0 rows affected (0.05 sec)
mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.07 sec)
MySQL5.6并行复制原理图：
并行复制参数说明：
slave_parallel_workers:
Number of applier threads for executing replication transactions in parallel. A value of 0 disables slave multithreading. Not supported by MySQL Cluster
MySQL5.7并行复制原理：
基于组复制（group commit）实现
如何知道事务是否在同一组中？
在MySQL 5.7版本中，其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能，即：将参数gtid_mode设置为OFF呢？
MySQL 5.7引入了称之为Anonymous_Gtid（ANONYMOUS_GTID_LOG_EVENT）的二进制日志event类型，组提交信息存放在 Anonymous_Gtid 中。
当开启GTID时，每一个操作语句（DML/DDL）执行前就会添加一个GTID事件，记录当前全局事务ID；同时在MySQL 5.7版本中，组提交信息也存放在GTID事件中，有两个关键字段last_committed，sequence_number就是用来标识组提交信息的。在InnoDB中有一个全局计数器（global counter），在每一次存储引擎提交之前，计数器值就会增加。在事务进入prepare阶段之前，全局计数器的当前值会被储存在事务中，这个值称为此事务的commit-parent（也就是last_committed）。last_committed表示事务提交的时候，上次事务提交的编号，如果事务具有相同的last_committed，表示这些事务都在一组内，可以进行并行的回放。而sequence_number是顺序增长的，每个事务对应一个序列号。
这意味着在MySQL 5.7版本中即使不开启GTID，每个事务开始前也是会存在一个Anonymous_Gtid，而这个Anonymous_Gtid事件中就存在着组提交的信息。反之，如果开启了GTID后，就不会存在这个Anonymous_Gtid了，从而组提交信息就记录在非匿名GTID事件中。
MySQL如何将这些事务进行分组的？
一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）
MySQL5.7并行复制简介：
1）MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave云服务器的回放与master是一致的，即master云服务器上是怎么并行执行的，那么slave上就怎样进行并行回放。不再有库的并行复制限制，对于二进制日志格式也无特殊的要求（基于库的并行复制也没有要求）
2）MySQL5.7并行复制支持表级
3）Enhanced Multi-threaded Slaves（MTS）
MySQL5.7并行复制参数：
SHOW VARIABLES LIKE 'slave_parallel_%'
Variable_name Value
slave_parallel_type DATABASE （变量slave-parallel-type可以有两个值：DATABASE 默认值，基于库的并行复制方式；LOGICAL_CLOCK：基于组提交的并行复制方式（基于表））
slave_parallel_workers 0
MySQL 5.7并行复制配置与调优：
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
MySQL5.7在线开启并行复制（多线程复制）：
参考视频：https://www.imooc.com/video/10921
在Slave云服务器上停止所有链路的复制
stop slave
set global slave-parallel-type=LOGICAL_CLOCK
set global slave-parallel-workers=16
start slave
show processlist（看到16个SQL线程）
MySQL5.7应用事务顺序和realy log记录事务顺序不一样的问题：
MySQL 5.7后的MTS可以实现更小粒度的并行复制，但需要将slave_parallel_type设置为LOGICAL_CLOCK，但仅仅设置为LOGICAL_CLOCK也会存在问题，因为此时在slave上应用事务的顺序是无序的，和relay log中记录的事务顺序不一样，这样数据一致性是无法保证的，为了保证事务是按照relay log中记录的顺序来回放，就需要开启参数slave_preserve_commit_order
以上关于MySQL并行复制配置与调优的操作详细内容，对大家有帮助吗？如果想要了解更多相关，可以继续关注我们的行业资讯板块。
