Another reason for Xtrabackup error “log block numbers mismatch”

http://www.chriscalender.com/another-reason-for-xtrabackup-error-log-block-numbers-mismatch/

Another reason for Xtrabackup error “log block numbers mismatch”

I ran into an issue the other day where Xtrabackup was not completing and threw the following error:

xtrabackup: error: log block numbers mismatch:
xtrabackup: error: expected log block no. 134860907, 
but got no. 176803931 from the log file.
xtrabackup: Error: xtrabackup_copy_logfile() failed.

When researching this error, I found that this error is generally caused when the following 2 conditions must are met, and this is generally when “xtrabackup cannot catch up with log writing activity on the server, so the log wraps around before xtrabackup can copy records before they are overwritten”:

  1. The log block numbers must wrap around, which only happens once per 1 GB of log writes.
  2. The wrap-around point must be between the last checkpoint and the current log tail at the time the backup starts.

Discussed here:
https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309
https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355

When this does occur as a result of the above (and not a bug), then it’s usually an I/O issue, either on the MySQL-side or the disk-side. One you can check with the /dev/null redirect of the actual data (i.e., if it then completes, perhaps you have some IO issue, so investigate that, and/or perform during a period of low-activity).

In this specific case, however, it was a new version of Xtrabackup, low-load, 6G InnoDB log files, …

So what was the problem?

Here the user was trying to use the “xtrabackup” binary to dump a MySQL 5.6 instance. Once switched to “xtrabackup_56” binary, as described here, it worked as expected.

Hope this helps.

 

你可能感兴趣的:(mysql)