一、问题描述

收到从库写入失败的报警，于是上线查看，发现主要是由备份引起，但线上的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：https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355
• 链接2：https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309
• 链接3：https://blog.csdn.net/caoshulin1989/article/details/73332379

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

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

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

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

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