目录

• • 备库并行复制能力
  • MySQL5.6版本 并行复制策略
  • MariaDB 并行复制策略
  • MySQL5.7版本 并行复制策略
  • MySQL5.7.22版本 并行复制策略
  • 总结

备库并行复制能力

主要涉及两个方面的并行度：

1、客户端写入主库的能力

2、备库上sql_thread执行中转日志relay log

1的并行能力比2强。

主库上由于InnoDB支持行锁，对业务并行度的支持比较友好。

备库上如果用单线程，会导致备库应用日志不够快，造成主备延迟。

现在MySQL使用的是多线程复制

coordinator 就是原来的sql_thread，不过现在它不再直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，是worker线程。线程个数由slave_parallel_workers决定，一般设置为8~16。

coordinator在分发事务的时候，要遵循两个要求：

• 不能造成更新覆盖。也就是说更新同一行的两个事务必须被分发到同一个worker中。
• 同一个事务不能被拆开，必须放到同一个worker中。

MySQL5.6版本 并行复制策略

支持粒度：库

用于决定分发策略的hash表key值：数据库名

优势：

1、构造hash值快；一个实例上的DB数目不会很多。

2、不要求binlog格式。row和statement格式的binlog都可以拿到库名。

缺点：

1、主库表在同一个DB中，策略失效

2、不同DB热点不同，起不到并行效果

MariaDB 并行复制策略

策略：

1、能够在同一组里提交的事务，一定不会修改同一行

2、主库上可以并行执行的事务，备库上一定是可以并行执行的

为了实现该策略，MariaDB实现方法为：

1、在一组里面一起提交的事务，有一个相同的commit_id，下一组就是commit_id+1

2、commit_id直接写到binlog里

3、传到备库应用的时候，相同commit_id的事务分发到多个worker执行

4、一组全部执行完后，coordinator再去取下一批

这个策略目标就是备库模拟主库的并行模式。

不过主库再一组事务commit的时候，下一组事务实际上是处于"执行中"状态的。

而按照MariaDB策略，在备库上执行的时候，要等一组事务完全执行完，下一组事务才能开始执行，这样系统的吞吐量就不够。

这个策略，对于长事务来说不友好。如果一组里有一个超大事务线程，该组其他线程执行完后要等待这个线程执行完，之后才能切换到下一组。这段时间，只有一个线程进行工作，浪费了资源。

MySQL5.7版本 并行复制策略

策略思想：

1、同时处于prepare状态的事务，在备库执行时是可以并行的

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

通过调节binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count参数

来来拉长binlog从write到fsync的时间，以此减少binlog’的写盘次数。同时在并行复制策略里，可以用来制造更多“同时处于prepare阶段的事务”。这样就能增加备库复制的并行度。

通俗来讲，这两个参数，既可以让主库提交慢一点，又可以让备库执行快一点。在MySQL5.7处理备库延迟时，可以调节这两个参数，达到提升备库复制并行度的目的。

MySQL5.7.22版本 并行复制策略

新增了一个参数binlog-transaction-dependency-tracking，用来控制是否启用这个新策略。

可选值：

1、COMMIT_ORDER，表示根据同时进入prepare和commit来判断是否可以并行

2、WRITESET,表示对于事务涉及更新的每一行，计算出这一行的hash值，组成集合writeset。如果两个事务没有操作相同的行，即writeset没有交集，就可以并行。

3、WRITESET_SESSION，在WRITESET基础上多了一个约束：在主库上同一线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序

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

这个版本的好处在于：

--1、writeset是在主库生成后直接写入到binlog里的，在备库执行的时候，不需要解析binlog内容，节省了备库计算量
--2、不需要把整个事务的binlog都扫一边才能决定分发到哪个worker，更加节省内存
--3、备库的分发策略不依赖于binlog内容，所以binlog是statement格式也是可以的

对于表上没有主键和外键约束的场景，WRITSET策略也没有办法并行，会暂时退化为单线程模型。 所以，表是否有主键，也是影响主备同步延迟原因之一。

总结

单线程复制能力低于多线程复制，对于更新压力较大的主库，备库可能一直追不上主库。

MySQL备库并行策略，修改了binlog的内容，也就是说不是向上兼容的，所以需要注意。