Bug #88770 Assertion failure in file during InnoDB recovery
Submitted: 6 Dec 2017 3:14 Modified: 11 Jan 2018 13:41
Reporter: Jaejeong Hwang Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:5.5.28 OS:CentOS (Linux 3.10.0-693.5.2.el7.x86_64 x86_64)
Assigned to: CPU Architecture:Any

[6 Dec 2017 3:14] Jaejeong Hwang
Description:
Assertion failure in file /export/home/pb2/build/sb_0-18784902-1462436607.89/mysqlcom-pro-5.6.29/storage/innobase/page/page0zip.cc line 4236

###############################################################################
...

171206 11:09:00 mysqlbackup_64bit_312: INFO: Compressed files removed successfully
171206 11:09:00 mysqlbackup_64bit_312: INFO: Uncompress operation completed successfully.

 mysqlbackup_64bit_312: INFO: Creating 12 buffers each of size 65678.
171206 11:09:00 mysqlbackup_64bit_312: INFO: Apply-log operation starts with following threads
                1 read-threads    1 process-threads
 mysqlbackup_64bit_312: INFO: Using up to 300 MB of memory.
171206 11:09:00 mysqlbackup_64bit_312: INFO: ibbackup_logfile's creation parameters:
          start lsn 14246244000256, end lsn 14250261334763,
          start checkpoint 14246244000697.
InnoDB: Doing recovery: scanned up to log sequence number 14246249243136
InnoDB: Doing recovery: scanned up to log sequence number 14246254486016
InnoDB: Doing recovery: scanned up to log sequence number 14246259728896
InnoDB: Doing recovery: scanned up to log sequence number 14246264971776
InnoDB: Doing recovery: scanned up to log sequence number 14246270214656
InnoDB: Doing recovery: scanned up to log sequence number 14246275457536
InnoDB: Doing recovery: scanned up to log sequence number 14246280700416
InnoDB: Doing recovery: scanned up to log sequence number 14246285943296
InnoDB: Doing recovery: scanned up to log sequence number 14246291186176
InnoDB: Doing recovery: scanned up to log sequence number 14246296429056
InnoDB: Doing recovery: scanned up to log sequence number 14246301671936
InnoDB: Doing recovery: scanned up to log sequence number 14246306914816
InnoDB: Doing recovery: scanned up to log sequence number 14246312157696
InnoDB: Doing recovery: scanned up to log sequence number 14246317400576
InnoDB: Doing recovery: scanned up to log sequence number 14246322643456
InnoDB: Doing recovery: scanned up to log sequence number 14246327886336
InnoDB: Doing recovery: scanned up to log sequence number 14246333129216
InnoDB: Doing recovery: scanned up to log sequence number 14246338372096
 mysqlbackup_64bit_312: INFO: InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 2017-12-06 11:09:05 7fc25bfff700  InnoDB: Assertion failure in file /export/home/pb2/build/sb_0-18784902-1462436607.89/mysqlcom-pro-5.6.29/storage/innobase/page/page0zip.cc line 4236
InnoDB: Failing assertion: slot
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

How to repeat:
After copying the backup file and uncompressing, a message confirms that the operation is successful, but errors occur.
[11 Dec 2017 13:41] MySQL Verification Team
Hi!

Assertion failure occurs during restore, which is performed by a product that does not looks like being ours.

Our product is MEB. If you are using Mysql Enterprise Backup, then please let us know the exact version of MEB that you are using.

If you are not using MEB, but some third party product, we warmly recommend you to report this bug to them.

Thank you for your report.
[12 Jan 2018 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".