首先，我们来看备份的日志，在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个文件。

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