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

Bug #1164979 reported by Alexey Kopytov on 2013-04-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Medium
Laurynas Biveinis
2.0
Fix Released
Medium
Laurynas Biveinis
2.1
Fix Released
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.

Related branches

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

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

Other bug subscribers