一、介绍

在官方的 5.6 版本之前，MySQL 只支持单线程复制，由此在主库并发高、TPS 高时就会出现严重的主备延迟问题。

如果备库执行日志的速度持续低于主库生成日志的速度，那么主从延迟就有可能成了小时级别。而且对于一个压力持续比较高的主库来说，备库很可能永远都追不上主库。

1>MySQL 5.6版本的并行复制策略

官方 MySQL5.6 版本，支持了并行复制，只是支持的粒度是按库并行。这个策略的并行效果，取决于压力模型。如果在主库上有多个 DB，并且各个 DB 的压力均衡，使用这个策略的效果会很好。

优点：实现逻辑简单，binlog格式同时支持statement和row。

缺点：如果热点数据在同一个DB，则没有并行效果了。另外在企业级架构设计时，DBA会用多实例单库的模式来分解多个DB的并行压力。

2>MySQL 5.7版本的并行复制策略

在官方的 MySQL5.7 版本中，由参数 slave-parallel-type 来控制并行复制策略：

  1. 配置为 DATABASE，表示使用 MySQL 5.6 版本的按库并行策略；
  2. 配置为 LOGICAL_CLOCK，代表 MySQL 5.7 这个引入的新的并行策略。

原理：redo log组提交（group commit）策略，为同一组一起提交的事务维护一个commit_id,并写入binlog日志。日志传到备库后，coordinator会以轮询的方式将相同commit_id的事务分发到多个worker执行，待一组执行完成后，再取下一批。

MySQL 5.7.22 版本里，MySQL 增加了一个新的并行复制策略，基于 WRITESET 的并行复制。新增了一个参数 binlog-transaction-dependency-tracking，用来控制是否启用这个新策略，默认为commit_order，即上面介绍的这种。

二、开启并行复制 
 

  1. slave_parallel_type = LOGICAL_CLOCK

  2.  

  3. slave_parallel_workers = 8

  4.  

  5. binlog_transaction_dependency_tracking=COMMIT_ORDER

注意

在MySQL 5.7.22中，默认binlog_transaction_dependency_tracking=commit_order,但是slave_parallel_type=database，此时我们以slave_parallel_type=database为准。

三、优化选项

1>设置并发线程数

slave_parallel_workers

建议把这个值设置为 8~16 之间最好（32 核物理机的情况），毕竟备库还有可能要提供读查询，不能把 CPU 都吃光了。

2>binlog组提交控制

binlog_group_commit_sync_delay 参数，表示延迟多少微秒后才调用 fsync;

binlog_group_commit_sync_no_delay_count 参数，表示累积多少次以后才调用 fsync。

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

也就是说，这两个参数，既可以“故意”让主库提交得慢些，又可以让备库执行得快些。在 MySQL 5.7 处理备库延迟的时候，可以考虑调整这两个参数值，来达到提升备库复制并发度的目的。