码迷,mamicode.com
首页 > 其他好文 > 详细

备份宽带不足,innobackupex备份导致从库不可写

时间:2019-09-17 12:59:25      阅读:139      评论:0      收藏:0      [点我收藏+]

标签:back   操作   tar   dev   级别   inno   参考   没有   copy   

  一、问题描述

       收到从库写入失败的报警,于是上线查看,发现主要是由备份引起,但线上的MySQL众多,其它实例都没问题,只有这个实例报了,一定有其它原因,继续查找。

首先,我们来看备份的日志,在20:14:16的时候,备份程序将idb文件备份完,然后开始准备备份frm文件,首先执行flush no_write_to_binlog tables,然后执行flush tables with read lock,这都没问题,

但这从一秒开始,会阻塞住从库的DDL和DML操作。由于备份日志太长了,下面我只截取其中的一部分重要的提示。

20:14:20的时候,提示:Finished backing up non-InnoDB tables and files,也就是从20:14:16秒开始备份frm文件,到备份结束,只用4秒,这个符合预期,没什么问题。

但接着的flush no_write_to_binlog engine logs却运行了33分钟左右,然后才执行table unlock。问题就是出在这33分钟这里,锁住的时间太久,触发了报警。

 

技术图片

技术图片

 

二、排查过程

1、查看log_file的参数设置,发现log_file设置成了8G,并且设置了12个文件。

> show variables like ‘%innodb_log_file%‘;
+---------------------------+------------+
| Variable_name | Value |
+---------------------------+------------+
| innodb_log_file_size | 8589934592 |
| innodb_log_files_in_group | 12 |
+---------------------------+------------+
2 rows in set (0.00 sec)

8.0G ib_logfile0
8.0G ib_logfile1
8.0G ib_logfile10
8.0G ib_logfile11
8.0G ib_logfile2
8.0G ib_logfile3
8.0G ib_logfile4
8.0G ib_logfile5
8.0G ib_logfile6
8.0G ib_logfile7
8.0G ib_logfile8
8.0G ib_logfile9

2、但调这个参数是有原因的,那就是innobackupex的需要,如果把参数改小,如下(需要重启实例),再次备份会出现报错:

修改为256M,共4个文件

show variables like ‘%innodb_log_file%‘;
+---------------------------+-----------+
| Variable_name | Value |
+---------------------------+-----------+
| innodb_log_file_size | 268435456 |
| innodb_log_files_in_group | 4 |
+---------------------------+-----------+

将文件调小之后,再次备份,出现的报错是:

xtrabackup: error: it looks like InnoDB log has wrapped around before xtrabackup could process all records due to either log copying being too slow, or log files being too small.
3880 xtrabackup: Error: xtrabackup_copy_logfile() failed.

关于这个问题,下面的文章有说明,我这个实例数据大小是2.2T,通过压缩备份之后的大小是接近1.2T,另外我们用的是异地备份,文件拷贝做了限速,所以备份花费了近12个小时,这也导致了ib_logfile文件不能调小,否则备份不成功。

技术图片

 

 

3、看到一个贴子说是网络宽带的问题,后面我也测试了一下,用这个命令测试备份是否成功,innobackupex --defaults-file=/data/mysql/3306/my.cnf --user=xxxx --password=xxxx --stream=tar  /data/tmp >/dev/null

扫日志马上完成(同一秒完成),不会导致延迟的产生。开始备份的时间是:09:45:12,开始锁表的时间是:11:05:50秒,解锁的时间是:11:05:51,相当于只锁了1秒钟,结束备份的时间是11:06:49,整个备份耗时只是81分钟左右。

技术图片

 

 

 

 技术图片

 

技术图片

 

 

 

 

  

参考文章

 

三、目前存在的风险和完善

      1、这个实例在备份期间,会导致实例只读33分钟,只能提供查询,虽然是从库,但这33分钟属于从库延迟的状态,对于不允许从库延迟的业务,也是不合适的。目前这个从库没有业务,全部业务都访问主库;

      2、备份锁表期间,出现从库延迟,如果这个时候主库出现硬件故障,MHA不能完成自动故障切换,会因从库延迟而提示切换失败(切换逻辑待完善)

      3、针对不可写入的监控,对于这种情况引起的写入失败,不做为灾难级别的报警。

 

 

备份宽带不足,innobackupex备份导致从库不可写

标签:back   操作   tar   dev   级别   inno   参考   没有   copy   

原文地址:https://www.cnblogs.com/tonnyChen/p/11429048.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!