https://blog.csdn.net/demonson/article/details/80774899
MySQL主从复制的备库延迟一直是非常头疼的问题，MySQL5.7官方版推出多线程复制。但是无独有偶，前期测试MySQL5.7.12， 发现有CRASH的情况，所以一直没有着手研究测试MySQL5.7，提交官方BUG（https://bugs.mysql.com/81445），在等了五个月以后终于解决，在MySQL5.7.16版本CRASH的情况没有发生，并且持续压测了48小时，TPS，日志告警，系统负载等各个方面指标基本稳定，无任何异常，与MySQL5.6在稳定性上面的测试基本一致，因此完全满足目前生产的的上线要求，因此开始着手测试MySQL官方版本令人兴奋的MTS多线程复制。
1. 备库参数修改
# slave
slave_parallel-type=LOGICAL_CLOCK
#DATABASE 默认值，基于库的并行复制方式
#LOGICAL_CLOCK：基于组提交的并行复制方式
slave_parallel_workers=24
#并行的SQL线程数量，此参数只有设置 1<N的情况下才会才起N个线程进行SQL重做。
#经过测试对比发现， 如果主库的连接线程为M， 只有M < N的情况下， 备库的延迟才可以完全避免。
#否则，延迟一样的会存在，但是毕竟SQL重做线程从原来的一个，升级到现在的N个， 这个延迟在一定的主库TPS下会很短！
master_info_repository=TABLE
relay_log_info_repository=TABLE
#这两个参数会将master.info和relay.info保存在表中，默认是Myisam引擎，官方建议改为Innodb引擎，防止表损坏后自行修复。
#alter table slave_master_info engine=innodb;
#alter table slave_relay_log_info engine=innodb;
#alter table slave_worker_info engine=innodb;
relay_log_recovery=ON
#当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这#样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启。
2. 备库其他建议参数
提高备库的TPS，能够更好的缓解备库的延迟，有以下参数优化可以提高备库的性能：
2.1 关闭备库binlog
2.2 sync_binlog = 0 && innodb_flush_log_at_trx_commit=0
关闭备库的binlog校验。
3. 总结
从测试结果来看，MySQL5.7的多线程复制，到目前mysql5.7.16版本从稳定性上面来说已经具备生产的上线条件。并且在一定的TPS范围以内能够避免备库的大延迟，但并非完全避免了备库的延迟。从正常的角度来看也是可以理解的，就算备库的slave_parallel_workers设置再大，也不可能大过主库的用户线程。经过初步测试，我们目前的生产环境，CPU两路32CORE,128G内存，普通机械盘，这种配置下面，主库TPS超过3万，备库的延迟会逐步增加。主库3W以内的TPS，备库无任何延迟。