背景

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_%';

此次配置结果如下:

image-20210830110403950