MySQL主备同步延迟

今天看到mycat的日志，发现在wrapper.log中频繁warning：slave延迟23006秒

查看数据指标：

show engine innodb status正常，而且slave的拷贝点在移动，说明salve复制正常。

从中午开始进行多线程写入数据，考虑到现在配置的MySQL主从复制是单线程的，有可能是因为数据写入太多，复制落后。
现在考虑GTID复制，GTID支持多线程复制，并且按照组提交和库设置并行。
此外还可以设置：MySQL支持使用 slave_compressed_protocol参数进行日志压缩复制。这种方法将减少高达80%的服务器之间的通信。
slave_compressed_protocol = 1
下面附上数据库配置方法：
1. 备库参数修改
# slave
slave_parallel-type=LOGICAL_CLOCK
#DATABASE 默认值，基于库的并行复制方式
#LOGICAL_CLOCK：基于组提交的并行复制方式
slave_parallel_workers=24
#并行的SQL线程数量，此参数只有设置 1#经过测试对比发现， 如果主库的连接线程为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校验。

转载于:https://www.cnblogs.com/AndersonX/p/8696428.html