MySQL的复制延迟是一直被诟病的问题之一,在MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进。总之,MySQL 5.7版本后,复制延迟问题永不存在。并行复制主要是解决sql_thread在高并发环境下,存在性能瓶颈。mysql5.7并行复制的思想简单易懂,一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交)。

为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有:

 (1)DATABASE:默认值,基于库的并行复制方式

 (2)LOGICAL_CLOCK:基于组提交的并行复制方式


操作步骤:

数据库版本信息

mysql 并行复制_第1张图片


复制类型 基于binlog文件名和位置【也可采用GTID方式】

mysql 并行复制_第2张图片


在slave 的my.cnf增加配置,然后重启slave。

[mysqld]

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=8

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON


重新start slave;发现有8个coordinator线程。

mysql 并行复制_第3张图片


   如何知道事务是否在一组中,因为原版的MySQL并没有提供这样的信息。在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能,即将参数gtid_mode设置为OFF呢?故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型。

mysql 并行复制_第4张图片


last_committed值相同的为一组,可以并行执行。

wKioL1heCJ_iv6rhAAAvMM7DH-8052.png


监控并行复制的信息

"root@localhost:mysql9000.sock  [performance_schema]>show tables like 'replication%';

+---------------------------------------------+

| Tables_in_performance_schema (replication%) |

+---------------------------------------------+

| replication_applier_configuration           |

| replication_applier_status                  |

| replication_applier_status_by_coordinator   |

| replication_applier_status_by_worker        |

| replication_connection_configuration        |

| replication_connection_status               |

| replication_group_member_stats              |

| replication_group_members                   |

+---------------------------------------------+

8 rows in set (0.00 sec)


并行复制配置与调优

master_info_repository

开启MTS功能后,务必将参数master_info_repostitory设置为TABLE,这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升,资源的竞争也会变大。在之前InnoSQL的版本中,添加了参数来控制刷新master.info这个文件的频率,甚至可以不刷新这个文件。因为刷新这个文件是没有必要的,即根据master-info.log这个文件恢复本身就是不可靠的。在推荐将master_info_repository设置为TABLE,来减小这部分的开销。

slave_parallel_workers

若将slave_parallel_workers设置为0,则MySQL 5.7退化为原单线程复制,但将slave_parallel_workers设置为1,则SQL线程功能转化为coordinator线程,但是只有1个worker线程进行回放,也是单线程复制。然而,这两种性能却又有一些的区别,因为多了一次coordinator线程的转发,因此slave_parallel_workers=1的性能反而比0还要差,有20%左右的性能下降。


   这里其中引入了另一个问题,如果主机上的负载不大,那么组提交的效率就不高,很有可能发生每组提交的事务数量仅有1个,那么在从机的回放时,虽然开启了并行复制,但会出现性能反而比原先的单线程还要差的现象,即延迟反而增大了。