【MySQL】开启并行复制

一、介绍

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

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

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

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

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

缺点:如果热点数据在同一个DB,则没有并行效果了。另外在企业级架构设计时,DBA会用多实例单库(共享存储,多个mysql实例)的模式来分解多个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,即上面介绍的这种。

二、开启并行复制

slave_parallel_type = LOGICAL_CLOCK

slave_parallel_workers = 8

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

 

 

 

转载于:https://my.oschina.net/u/3478888/blog/3004146

【MySQL】开启并行复制

上一篇:MySQL之——MyISAM与InnoDB


下一篇:SQL 分组(group by和having)