Mysql各版本备库的并行复制策略

Mysql从库的并行复制策略：

目的：提高备库应用日志的效率，解决由于主库并发高、备库应用日志慢导致的主备延迟的问题

Mysql 5.6之前：
    单线程复制
    
Mysql 5.6：
    支持并行复制，粒度为按库并行。每一个worker上构建一个hash列表，同一个库的事务会被分配一个worker里。
优势：
    1.以库为单位，构建hash列表会很快且不会太大
    2.binlog的格式不需要是row，statement格式的日志也可以获取到库名
缺陷：
    粒度太大，库内无法并行，对于那些业务大部分集中在某个db的场景，效率接近于单线程复制

MariaDB：
    按组提交(利用redo log的组提交特性，在同一组提交的事务一定不会修改同一行)
    在一组里一起提交的事务，在binlog里都会有一个相同的commit_id，传到备库后相同commit_id的事务可以分发到多个worker执行
缺陷：
    不在同一组的事务无法在备库上并行，备库的吞吐量不足，且容易被大事务影响    
    
Mysql 5.7：
    增加参数slave-parallel-type来控制并行复制策略：
    1.配置为database，则按照Mysql5.6的策略执行
    2.配置为logical_clock，则按照一种类似于MriaDB的思路进行：
        1)同时处于 prepare 状态的事务，在备库执行时是可以并行的
        2)处于 prepare 状态的事务，与处于 commit 状态的事务之间，在备库执行时也是可以并行的
    在通过参数binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count来拉长binlog write和fsync之前的时间，制造更多"同时处于"prepare阶段的事务

Mysql 5.7.22：
    在原有的基础上新增了writeset的并行复制策略，通过参数binlog-transaction-dependency-tracking来控制，可选值有三种：
        1)COMMIT_ORDER：之前5.7版本的并行复制方式
        2)WRITESET：对事务涉及更新的每一行计算hash，组成集合WRITESET,两个事务的WRITESET没有交集的话，那么他们可以并行执行(表上无主键or表上有外键时，使用该策略无法并行)
        3)WRITESET_SESSION：在WRITESET的基础上增加约束，即在主库上同一线程先后执行的两个事务，在备库上也要保证其执行的先后顺序
    
    WRITESET的优势：
        1)WRITESET是在主库执行后写到binlog里的，因此备库执行不需要解析binlog来生成WRITESET
        2)分发任务时不需要扫描事务的整个binlog内容
        3)由于备库分发策略不依赖于binlog的内容，所以binlog的格式可以是statement的