Too weak condition (no < scanned_no) in log copying thread

[Sergei Glushchenko]

If xtrabackup detected that log block which been just read has the
different number from what is expected it is trying to determine
whether it is OK or something went wrong and the backup has to be
aborted.

Possible cases are:

1. Log is just not flushed to position we are trying to read from. In
  this case we'll see log block which is older than we expect.
2. We are trying to read from wrong position and must retry (PS 5.5
  with large log files)
3. We are too slow to read from redo log and InnoDB has wrapped
  around before we could catch up (rare case).

Following condition for case (1) is too weak:

  if (no < scanned_no ||
   /* Log block numbers wrap around at 0x3FFFFFFF */
   ((scanned_no | 0x40000000UL) - no) %
   blocks_in_group == 0) {

More accurate condition will be:

   (no < scanned_no && ((scanned_no - no) % blocks_in_group) == 0) ||
   (((scanned_no | 0x40000000UL) - no) % blocks_in_group) == 0

It means that log block number for the same offset advancing by the
blocks_in_group increments.

[Sergei Glushchenko (sergei.glushchenko)]

https://github.com/percona/percona-xtrabackup/pull/110

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-437