xtrabackup_56 can fail on prepare if log files > 4G used on source server

Reported by Alexey Kopytov on 2013-04-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Medium
Laurynas Biveinis
2.0
Medium
Laurynas Biveinis
2.1
Medium
Laurynas Biveinis

Bug Description

The patch to support 5.6 added support for log files > 4G. However that code was incomplete. When xtrabackup adjusts the log header so recovery can later find the record it needs, we now do this:

 mach_write_to_4(log_buf + LOG_CHECKPOINT_1
   + LOG_CHECKPOINT_OFFSET_LOW32,
   LOG_FILE_HDR_SIZE + (ulint) ut_dulint_minus(max_lsn,
   ut_dulint_align_down(max_lsn,OS_FILE_LOG_BLOCK_SIZE)));

i.e. that code only overwrites the low 32 bits of LOG_CHECKPOINT_OFFSET (which is used by recovery to calculate file offsets from LSN), but it leaves the high 32 bits intact. Which means if the server log happened to contain a non-zero value in LOG_CHECKPOINT_OFFSET_HIGH32 at the time the backup was started (which is only possible with log files > 4G), InnoDB recovery on xtrabackup --prepare will be using incorrect file offsets.

The fix is to also overwrite LOG_CHECKPOINT_OFFSET_HIGH32 with 0 in xtrabackup_56.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers