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

曾经终败给现在 2022-12-20 03:14 83阅读 0赞

## [备份宽带不足，innobackupex备份导致从库不可写][innobackupex] ##

#   一、问题描述 #

收到从库写入失败的报警，于是上线查看，发现主要是由备份引起，但线上的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分钟这里，锁住的时间太久，触发了报警。

![e8f323155f78d21ab3aa50de4761d1fb.png][]

![daec55d9478a1923364004f45e1c0cf1.png][]

# 二、排查过程 #

1、查看log\_file的参数设置，发现log\_file设置成了8G，并且设置了12个文件。

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文件不能调小，否则备份不成功。

![ff983b08f5d454e3c0f78c6cb189a1f1.png][]

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分钟左右。

![d5303fc410aacd1c4cc87bfefa94f1b8.png][]

![e8d163925354f30589bb52dfced3c68b.png][]

![7921905c8e619df79f272bce3eaa9438.png][]

## 参考文章 ##

*  链接1：[https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355][https_bugs.launchpad.net_percona-xtrabackup_bug_1050355]
 *  链接2：[https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309][https_bugs.launchpad.net_percona-xtrabackup_bug_1206309]
 *  链接3：[https://blog.csdn.net/caoshulin1989/article/details/73332379][https_blog.csdn.net_caoshulin1989_article_details_73332379]

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

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

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

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

[innobackupex]: https://www.cnblogs.com/tonnyChen/p/11429048.html
[e8f323155f78d21ab3aa50de4761d1fb.png]: /images/20221120/8de42a62965e4468ac6edcc1aa051f6b.png
[daec55d9478a1923364004f45e1c0cf1.png]: https://img-blog.csdnimg.cn/img_convert/daec55d9478a1923364004f45e1c0cf1.png
[ff983b08f5d454e3c0f78c6cb189a1f1.png]: https://img-blog.csdnimg.cn/img_convert/ff983b08f5d454e3c0f78c6cb189a1f1.png
[d5303fc410aacd1c4cc87bfefa94f1b8.png]: https://img-blog.csdnimg.cn/img_convert/d5303fc410aacd1c4cc87bfefa94f1b8.png
[e8d163925354f30589bb52dfced3c68b.png]: https://img-blog.csdnimg.cn/img_convert/e8d163925354f30589bb52dfced3c68b.png
[7921905c8e619df79f272bce3eaa9438.png]: https://img-blog.csdnimg.cn/img_convert/7921905c8e619df79f272bce3eaa9438.png
[https_bugs.launchpad.net_percona-xtrabackup_bug_1050355]: https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355
[https_bugs.launchpad.net_percona-xtrabackup_bug_1206309]: https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309
[https_blog.csdn.net_caoshulin1989_article_details_73332379]: https://blog.csdn.net/caoshulin1989/article/details/73332379