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分析处理

日志信息

大清早的起来,打开手机看到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

你可能感兴趣的:(mysql)