Details
-
Bug
-
Status: Done
-
High
-
Resolution: Fixed
-
None
-
None
-
None
Description
**Reported in Launchpad by Alexey Kopytov last update 24-03-2016 14:47:38
The compact_compressed test fails sporadically in the single binary branch (i.e. with a 5.6-based binary). No failures occurred before rebasing xtrabackup on MySQL 5.6.14. Also, no failures occur on PS/MySQL 5.6.
Which most likely means it is yet another redo log compatibility bug introduced somewhere between 5.6.12 and 5.6.14 which makes InnoDB 5.6 incompatible with redo log / data files created with lower major server versions.
Reporting it here for further investigation.
Symptoms:
After expanding the compacted compressed tablespaces and starting crash recovery, release xtrabackup build fails with the following assertion:
—
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 2013-11-27 09:05:48 7fac1d5fd700 InnoDB: Assertion failure in thread 140377203922688 in file page0zip.cc line 4351
InnoDB: Failing assertion: slot_rec
InnoDB: We intentionally generate a memory trap.
—
Debug builds fail as follows:
—
InnoDB: Doing recovery: scanned up to log sequence number 9916023 (42%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 2013-11-26 12:56:16 2b96047fe940 InnoDB: Assertion failure in thread 47923320580416 in file page0zip.cc line 3442
InnoDB: Failing assertion: !memcmp(page_zip->data + 38, page + 38, (38 + 36 + 2 * 10) - 38)
InnoDB: We intentionally generate a memory trap.
—
It might be a coincidence, but all failures occur only with page_size = 16KB, never with 8KB pages.