MySQL Bugs: #81700: Assertion failure in file page0zip.cc during InnoDB crash recovery

Bug #81700	Assertion failure in file page0zip.cc during InnoDB crash recovery
Submitted:	3 Jun 2016 4:40	Modified:	18 May 2018 15:06
Reporter:	monty solomon	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.6.25	OS:	CentOS (6.7)
Assigned to:		CPU Architecture:	Any

Description:
Assertion failure in thread 140097125480192 in file page0zip.cc line 3742

InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 52823434752
2016-06-03 04:33:06 19175 [Note] 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 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 2016-06-03 04:33:11 7f6ae765f700  InnoDB: Assertion failure in thread 140097125480192 in file page0zip.cc line 3742
InnoDB: Failing assertion: !*data
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.
04:33:11 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

How to repeat:
I created a new server using volumes created from an EBS snapshot of a running server and the new server failed during InnoDB crash recovery.

error log

Attachment: error.log (application/octet-stream, text), 19.64 KiB.

# rpm -qa | grep mysql-community
mysql-community-libs-5.6.25-2.el6.x86_64
mysql-community-devel-5.6.25-2.el6.x86_64
mysql-community-common-5.6.25-2.el6.x86_64
mysql-community-client-5.6.25-2.el6.x86_64
mysql-community-libs-compat-5.6.25-2.el6.x86_64
mysql-community-server-5.6.25-2.el6.x86_64

Hi,

You can not transport InnoDB tables by taking block device snapshots (what ever EBS means). Not while the server is running !!!!

The only two ways you can do it is by mysqldump / restore , or by using MEB.

This is even documented in our Reference manual.

Using the snapshots is the same as restarting the server. The snapshots are complete copies of the filesystems. The consistent snapshot is created after flushing MySQL to disk using FTWRL and then freezing the filesystems using fsfreeze. The new volumes are exact replicas of the original volumes. (EBS volumes are a feature of Amazon EC2).

Excerpt from 14.18.2 InnoDB Recovery
https://dev.mysql.com/doc/refman/5.7/en/innodb-recovery.html

To recover from a MySQL server crash, the only requirement is to restart the MySQL server. InnoDB automatically checks the logs and performs a roll-forward of the database to the present. InnoDB automatically rolls back uncommitted transactions that were present at the time of the crash.

Hi,

I know exactly what are the snapshots. No, InnoDB does not support that. Also FTWRL has minimal effect on InnoDB.

Not a bug.