~percona-core/percona-xtrabackup/2.0

Viewing all changes in revision 574.

  • Committer: Alexey Kopytov
  • Date: 2013-08-05 12:51:12 UTC
  • Revision ID: akopytov@gmail.com-20130805125112-f04jwp9jic0a756m
Bug #1206309: Xtrabackup 2.0.7 or 2.1.2 failed: expected log block
              no. 5458041, but got no. 1070811265 from the log file

The problem was a combination of 2 things:

1. InnoDB log block numbers wrap around at 0x40000000. So the next log
block after 1073741823 has number 0, rather than 1073741824.

2. XtraBackup uses the following logic to detect "old" blocks (i.e. the
current log tail after which it has to stop scanning): if the current
log block number is less than the current scanned log block number, it
is an old one, stop scanning.

#2 doesn't work in cases when log block numbers wrap around. I.e. we
might be looking at an old block with a number before they had wrapped
around, but the current "expected" number has already wrapped around.

Fixed by taking this into account when detecting old blocks: if
scanned_lsn is higher than the current block number, but setting the
corresponding bit in scanned_lsn (i.e. the value it would have without
wrapping around) makes it a multiple of blocks_in_group away from the
read block number, consider it an old block and stop scanning.

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: