并行复制的演进
MySQL最早的主备复制只有两个线程，IO 线程负责从主库接收 binlog 日志，并保存在本地的 relaylog 中，SQL线程负责解析和重放 relaylog 中的 event。当主库并行写入压力较大时，备库 IO 线程一般不会产生延迟，因为写 relaylog 是顺序写，但是 SQL线程重放的速度经常跟不上主库写入的速度，会造成主备延迟。如果延迟过大，relaylog 一直在备库堆积，还可能把磁盘占满。
在官方的5.6版本之前，MySQL只支持单线程复制，因此在主库并发高，TPS高时就会出现严重的主备延迟问题。从单线程复制到最新版本的多线程复制，中间的演化经历了好几个版本。
多线程复制，具体方法就是把sql_thread，拆成多个worker线程，由一个coordinator分发到不同的worker，实现并行复制。coordinator在分发的时候，需要满足以下这两个条件：
1.不能造成更新覆盖。也就是更新同一行的两个事务，必须被分发到同一个worker中。
2.同一个事务不能被拆开，必须放到同一个worker中。
MySQL 5.6版本的并行复制策略
MySQL 5.6版本支持了按库并行复制。按库并行复制的并行效果，取决于压力模型。如果在主库上有多个DB，并且各个DB的压力均衡，使用这个策略的效果会很好。但是，如果主库上的表都放在同一个DB里面，这个策略就没有效果了。
MariaDB的并行复制策略
在前面的文章中，我们介绍了redo log的组提交（group commit）优化，而MariaDB的并行复制策略利用的就是这个特性：
1.能够在同一组里提交的事务，一定不会修改同一行。
2.主库上可以并行执行的事务，备库上也一定是可以并行执行的。
在实现上，MariaDB是这么做的：
1.在一组里面一起提交的事务，有一个相同的
commit_id
，下一组就是
commid_id+1
;
2.commit_id直接写到binlog里面。
3.传到备库的时候，相同commit_id的事务分发到多个worker执行。
4.这一组全部执行完成后，coordinator再去取下一批。
MariaDB的方案很容易被大事务拖后腿。假如一组事务有trx1，trx2，trx3，trx2是一个超大事务。在应用到备库的时候，trx1，trx3执行完成后，只能等trx2执行完成，下一组才能开始执行。这段时间，只有一个worker线程在工作，是对资源的浪费。
MySQL 5.7的并行复制策略
在MariaDB并行复制实现后，官方的MySQL 5.7版本也提供了类似的功能，由参数
slave-parallel-type
来控制并行复制策略：
1.配置为
DATABASE
，表示使用MySQL 5.6版本的按库并行策略。
2.配置为
LOGICAL_CLOCK
，表示使用类似mariaDB的策略。MySQL 5.7对这个策略做了优化。
MySQL 5.7优化后的并行复制策略是：
1.同时处于prepare状态的事务，在备库执行时是可以并行的。
2.处于prepapre状态的事务，与处于commit状态的事务之间，在备库执行时也是可以并行的。
在前面我们讲binlog的组提交的时候，介绍过两个参数：
1.
binlog_group_commit_sync_delaya
参数，表示延迟多少微秒后才fsync。
2.
binlog_group_commit_sync_no_delay_count
参数，表示累积多少次以后才调用fsync。
这两个参数是用于故意拉长binlog从write到fsync的时间，以此减少binlog的写盘次数。在MySQL 5.7的并行复制策略里，它们可以用来制造更多的处于prepare阶段的事务，这样就增加里备库复制的并行度。
MySQL 5.7.22的并行复制策略
在5.7.22版本里，MySQL增加了基于
WRITESET
的并行复制策略。相应的，增加了一个参数
binlog-transaction-dependency-tracking
，用来控制是否启用这个新策略，这个参数的可选值有以下三种：
1.
COMMOT_ORDER
，表示的就是前面介绍的，根据同时进入prepare和commit来判断是否可以并行的策略。
2.
WRITESET
，表示的是如果对于事务涉及更新的每一行，计算出这一行的hash值，组成集合writeset。如果两个事务没有操作相同的行，也就是说 它们的writeset没有交集，就可以并行。
3.
WRITESET_SESSION
，是在WRITESET的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保证 相同的先后顺序。
对于“表上没主键”和“外键约束”的场景，WRITESET策略也是没法并行的，也会暂时退化为单线程模型。