故障现象
生产中的一组MySQL双主（主库A和主库B）+Keepalived高可用单写（主库A），出现B库高延时问题。检查B库复制状态如下图1：
（B库的复制状态—图1）
问题分析
1、和开发人员确认，这组MySQL双主每天有批量的数据导入操作，业务是网站展示前一天股票大盘指数，数据是由脚本批量导入，从而产生了复制延时。
2、通过对导数据脚本分析，导数据是对一个表先进行delete后进行insert操作；股指大盘展示数据只保留一天数据，因此确认不需要保留前一天数据，修改脚本先truncate表后insert数据，这样可以加快数据导入的速度，避免复制的延时。
3、检看表结构，表没有主键，没有主键会影响主从复制。
4、检查B库show full processlist（图2），有批量的查询操作，user是dm，host是localhost连接是本地执行的，接下来排查系统是否有定时任务。
5、查看进程（图3），有批量备份脚本执行，每天的备份脚本没有完成，并且不停的执行。
（B库processlist信息-图2）
（B库检查进程-图3）
处理问题过程
1、kill掉B库系统上的备份脚本进程
2、A库全备份传输到B库，从做A库到B库的复制
（A库作全备份并传到B库-图4）
3、B库导入A库的备份文件，过程中会有报错，因为备份文件含有GTID信息，需要登录到B库执行reset master清除GTID信息，导入备份文件时重新生成GTID，再次导入A库的备份文件时就可以成功导入。
（B库导入A库备份-图5）
4、从做A库到B库的复制
1）reset slave all; 清除B库复制信息
2）Change master to 从做配置A库到B库的复制
3）Start slave；开启复制
4）Show slave status\G 检查复制状态已经是双YES（图6）
5）查看Master_Log_File=relay_master_log_file &&read_master_log_pos=exec_master_log_pos（图7）
（B库复制状态-图6）
(B库复制状态-图7)
5、检查B库向A库的复制状态，由于B库执行了reset master清除了B库的GTID信息，所以A库复制报错1236找不到master的binary log。
（A库复制状态-图8）
6、恢复B库到A库的复制，执行change master后检查A库复制状态。
（A库复制状态-图9 ）
7、双主环境的双向复制状态都恢复正常。
总结
此次双主环境产生复制延时的原因，主要是B库的备份脚本不停的执行，造成B库有批量的慢查询，备份脚本在B库不停执行的同时A库导数据脚本在删除数据和插入数据，A库在删除数据使用delete数据影响删除效率，造成复制延时。另外A库导数据所涉及的表没有主键也影响了B库复制数据重放速度，产生了复制延时。为了避免故障再次发生，需要给表添加主键，增加复制重放数据的执行效率，优化导数据脚本和备份脚本，来防止再次出现复制产生大量的延时的问题。
原文地址：https://blog.51cto.com/9201316/2375218