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

Bug #1164979 reported by Alexey Kopytov on 2013-04-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Laurynas Biveinis
Laurynas Biveinis
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_FILE_HDR_SIZE + (ulint) ut_dulint_minus(max_lsn,

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.

Related branches

Alexey Kopytov (community): Approve on 2013-04-15
Alexey Kopytov (community): Approve on 2013-04-15
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers