MySQL5.7 多线程复制，配置和测试结果

缺乏、安全感 2022-05-22 10:58 162阅读 0赞

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，备库无任何延迟。