XtraBackup error：log block numbers mismatch分析处理

https://tyoung.me/2016/09/how_to_deal_with_xtrabackup_error_log_block_numbers_mismatch/

XtraBackup error：log block numbers mismatch分析处理

发表于 2016-09-11 | 分类于 MySQL | 0 | 阅读次数 27

日志信息

大清早的起来，打开手机看到Zabbix的邮件提醒，MariaDB数据库备份失败，数据库的备份计划已经正常运行将近一年了，于是对于这次备份失败很是好奇。远程连上服务器，查看XtraBackup备份日志的部分信息如下：

160910 00:05:01 Connecting to MySQL server host: localhost, user: xxx, password: set, port: xxx, socket: /var/lib/mysql/mysql.sock Using server version 10.0.23-MariaDB-enterprise-log innobackupex version 2.3.5 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 45cda89) incremental backup from 0 is enabled. xtrabackup: uses posix_fadvise(). xtrabackup: cd to /opt/mysql_data xtrabackup: open files limit requested 65535, set to 65535 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 Found and using lsn: 846260275194 for name backup-53309-all_databases xtrabackup: error: log block numbers mismatch: xtrabackup: error: expected log block no. 586990567, but got no. 587187167 from the log file. 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. xtrabackup: Error: xtrabackup_copy_logfile() failed.

原因分析

主要错误日志：

xtrabackup: error: log block numbers mismatch: xtrabackup: error: expected log block no. 586990567, but got no. 587187167 from the log file. 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.

从以上错误日志可以看出，大概的意思是说：
XtraBackup在顺序拷贝完redo log末尾的数据后，重新从redo log的起始位置去拷贝时，发现起始位置的log block no.与刚才尾部的no.不连续。

当然日志里也进一步给出了解释：
在XtraBackup处理完所有的redo log数据之前，redo log起始位置的数据就被后续写入的log覆盖掉了。原因可能是拷贝redo log的速度太慢了，或者redo log文件的大小设置太小了。

结合从网上找到的资料，引起以上问题的可能原因如下：

1. redo log的文件大小（innodb_log_file_size*innodb_log_files_in_group）设置过小；
2. XtraBackup拷贝redo log的速度有些慢（可能受其他的系统任务的比较频繁的磁盘IO影响）；
3. 如果备份文件是存储在远程文件系统上，则还有可能是受网络带宽较小或拥堵导致；

本次问题分析

redo log相关的系统变量：

innodb_log_files_in_group = 2 innodb_log_file_size = 50331648 # 48M

从以上设置可以看出，MariaDB设置的redo log大小是2 * 48M，文件大小设置的有些小。

备份文件是存在远程文件系统的，查看了下Zabbix系统监控的当时的网络流量很小，而且此前备份一直是正常的，排除网络带宽和流量拥堵的影响。

此时又想起了一件事……
备份计划是每天00:05开始的，就在上个月我在主库添加了一个定时任务，每天对某个日志表进行归档操作，执行时间也是00:05。
应该是这个导致了00:05后redo log的快速循环写入，同时redo log文件设置的总大小又不大，导致XtraBackup在备份的时候，出现错误“log block numbers mismatch”。

解决方法

由于innodb_log_file_size变量不能动态更改，暂时也不能重启数据库更改变量值。所以将XtraBackup的开始时间推迟了一段时间，以错开日志归档时的IO高峰期。

备份计划推迟后，昨天的备份没有再次出现错误，后续还待进一步观察是否会再次出现此错误。

参考文章

• 链接1：https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355
• 链接2：https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309