基于GTID的主从实践系列之④并行复制搭建及测试

并行复制最早在5.6就搞出来了，是一个库级别的并行复制（slave_parallel_type可以有两个值：DATABASE 默认值，基于库的并行复制方式；LOGICAL_CLOCK：基于组提交的并行复制方式），不太好用；所以实际上5.6的主从复制是一个串行的复制，这就导致复制延迟时有发生了

在5.7中有了另一个值后，配置并行复制基本成了标配

将slave_parallel_type设置为'LOGICAL_CLOCK'，slave_parallel_workers设置为大于0的值，即算是开启了并行复制

打开从库

show variables like '%parallel%';

将这个database修改为logical_clock，在此之前，需要先关闭sql_thread

stop slave sql_thread;

set global slave_parallel_type='LOGICAL_CLOCK';

start slave sql_thread;

show variables like '%parallel%';

将slave_parallel_workers设置为大于0的值

set global slave_parallel_workers=16;（网文的测试表明线程数在16个时候的QPS较为理想）

修改完线程数之后，最好重新执行以下stop slave/start slave；如果没有执行的话，有可能表面上增加了线程，实际上仍然没有开启并行复制！

用sysbench结合pt-heartbeat来做一次延迟测试

sysbench对100万行的5张表进行1000秒的压测，通过pt-heartbeat实时监测延迟结果

#查看当前线程的工作状态（☆）

use performance_schema;

select * from replication_applier_status_by_worker;

上面这个语句是用来检查当前线程工作状态的，可以看到当前确实是16个线程；如果在更改了slave_parallel_workers参数之后，没有重新slave的话，有可能这里仍然是单线程工作的情况

（我之前的测试就是修改之后没有重新slave，结果测试出来的延迟值达到了610s，和下图单线程的结果几乎没有太大区别）

将线程数设置为0，测试出的从库延迟如下

将线程数设置为16，测试出的从库延迟如下

可以看到16线程的情况下，延迟时间只有单线程工作情况下的18%，这个提升可以说是非常巨大了

除了上面的参数以外，一些必要的参数设置如下

相关的表可以在performance_schema库下进行查看

select * from replication_applier_configuration;

select * from replication_applier_status;           

select * from replication_applier_status_by_coordinator; 

select * from replication_applier_status_by_worker;       

select * from replication_connection_configuration;       

select * from replication_connection_status;             

select * from replication_group_member_stats;           

select * from replication_group_members;

关于并行复制中涉及到的组提交概念

通过mysqlbinlog工具可以看到组提交的相关信息