故障现象
生产中的一组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库复制数据重放速度,产生了复制延时。为了避免故障再次发生,需要给表添加主键,增加复制重放数据的执行效率,优化导数据脚本和备份脚本,来防止再次出现复制产生大量的延时的问题。