MySQL5.6版本的并行复制策略

MySQL5.6版本支持了并行复制，只是支持的粒度是按库并行。用于决定分发策略的hash表里，key是数据库名

这个策略的并行效果取决于压力模型。如果在主库上有多个DB，并且各个DB的压力均衡，使用这个策略的效果会很好

这个策略的两个优势：

• 构造hash值的时候很快，只需要库名
• 不要求binlog的格式，因为statement格式的binlog也可以很容易拿到库名

可以创建不同的DB，把相同热度的表均匀分到这些不同的DB中，强行使用这个策略

2、MariaDB的并行复制策略

redo log组提交优化，而MariaDB的并行复制策略利用的就是这个特性：

• 能够在同一个组里提交的事务，一定不会修改同一行
• 主库上可以并行执行的事务，备库上也一定是可以并行执行的

在实现上，MariaDB是这么做的：

1. 在一组里面一起提交的事务，有一个相同的commit_id，下一组就是commit_id+1
2. commit_id直接写到binlog里面
3. 传到备库应用的时候，相同commit_id的事务分发到多个worker执行
4. 这一组全部执行完成后，coordinator再去取下一批

下图中假设三组事务在主库的执行情况，trx1、trx2和trx3提交的时候，trx4、trx5和trx6是在执行的。这样，在第一组事务提交完成的时候，下一组事务很快就会进入commit状态

按照MariaDB的并行复制策略，备库上的执行效果如下图：

在备库上执行的时候，要等第一组事务完全执行完成后，第二组事务才能开始执行，这样系统的吞吐量就不够

另外，这个方案容易被大事务拖后腿。假设trx2是一个超大事务，那么在备库应用的时候，trx1和trx3执行完成后，下一组才能开始执行。只有一个worker线程在工作，是对资源的浪费

3、MySQL5.7版本的并行复制策略

MySQL5.7版本由参数slave-parallel-type来控制并行复制策略：

• 配置为DATABASE，表示使用MySQL5.6版本的按库并行策略
• 配置为LOGICAL_CLOCK，表示的就是类似MariaDB的策略。MySQL在此基础上做了优化

同时处于执行状态的所有事务，是不是可以并行？

不可以，因为这里面可能有由于锁冲突而处于锁等待状态的事务。如果这些事务在备库上被分配到不同的worker，就会出现备库跟主库不一致的情况

而MariaDB这个策略的核心是所有处于commit状态的事务可以并行。事务处于commit状态表示已经通过了锁冲突的检验了

其实只要能够达到redo log prepare阶段就表示事务已经通过锁冲突的检验了

因此，MySQL5.7并行复制策略的思想是：

1. 同时处于prepare状态的事务，在备库执行时是可以并行的
2. 处于prepare状态的事务，与处于commit状态的事务之间，在备库执行时也是可以并行的

binlog组提交的时候有两个参数：

• binlog_group_commit_sync_delay参数表示延迟多少微妙后才调用fsync
• binlog_group_commit_sync_no_delay_count参数表示基类多少次以后才调用fsync

这两个参数是用于故意拉长binlog从write到fsync的时间，以此减少binlog的写盘次数。在MySQL5.7的并行复制策略里，它们可以用来制造更多的同时处于prepare阶段的事务。这样就增加了备库复制的并行度。也就是说，这两个参数既可以故意让主库提交得慢些，又可以让备库执行得快些

作者：Java编程宇宙 链接：https://zhuanlan.zhihu.com/p/394921571 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

4、MySQL5.7.22的并行复制策略

MySQL5.7.22增加了一个新的并行复制策略，基于WRITESET的并行复制，新增了一个参数binlog-transaction-dependency-tracking用来控制是否启用这个新策略。这个参数的可选值有以下三种：

• COMMIT_ORDER，根据同时进入prepare和commit来判断是否可以并行的策略
• WRITESET，表示的是对于事务涉及更新的每一行，计算出这一行的hash值，组成集合writeset。如果两个事务没有操作相同的行，也就是说它们的writeset没有交集，就可以并行
• WRITESET_SESSION，是在WRITESET的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序

为了唯一标识，hash值是通过库名+表名+索引名+值计算出来的。如果一个表上除了有主键索引外，还有其他唯一索引，那么对于每个唯一索引，insert语句对应的writeset就要多增加一个hash值

1. writeset是在主库生成后直接写入到binlog里面的，这样在备库执行的时候不需要解析binlog内容
2. 不需要把整个事务的binlog都扫一遍才能决定分发到哪个worker，更省内存
3. 由于备库的分发策略不依赖于binlog内容，索引binlog是statement格式也是可以的

对于表上没主键和外键约束的场景，WRITESET策略也是没法并行的，会暂时退化为单线程模型