MySQL5.7并行复制实现

Author：think

Date：2022-6-4

背景

MySQL主从复制的延迟问题一直困扰着众多开发者许多年，直到MySQL5.6版本出现了并行复制功能，这一问题才能得到改善。但该版本的并行复制功能是以库为单位实现并行，如果热点数据都是在同一个库里，那这个功能基本上就失效了。因此，在MySQL 5.7中将并行复制功能的粒度降得更小，并行复制的性能才有了更好的提升。并行复制原理可参考这篇文章（MySQL 5.7 并行复制实现原理与调优 - Still water run deep - 博客园 (cnblogs.com)）

配置

**以下配置都是在mysql控制台下执行的。**参考文章（【MySQL】开启并行复制_zclinux的博客-CSDN博客_mysql 并行复制开启）

关闭同步线程

stop slave;

并行策略配置

set global slave_parallel_type='LOGICAL_CLOCK';

并发工作线程数配置

set global slave_parallel_workers=8;

binlog 事务依赖跟踪配置

set global binlog_transaction_dependency_tracking=COMMIT_ORDER;

开启同步线程

mysql> start slave;

优化选项

并发线程数设置

slave_parallel_workers

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

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 处理备库延迟的时候，可以考虑调整这两个参数值，来达到提升备库复制并发度的目的。

查看配置

通过以下命令可以查看当前并行复制的配置：

show variables like 'slave_parallel_%';

此次配置结果如下：