MySQL Bugs: #29221: InnoDB asserts in log0recv.c when

Bug #29221	InnoDB asserts in log0recv.c when
Submitted:	19 Jun 2007 21:32	Modified:	13 Sep 2007 14:40
Reporter:	Ron Parker
Status:	No Feedback
Category:	Server: InnoDB	Severity:	S1 (Critical)
Version:	5.0.22	OS:	Linux (RHEL 5)
Assigned to:	Marko Mäkelä	Target Version:

Description:
After shutting down and restarting our server, InnoDB reports that the database was not
shut down normally, starts crash recovery and while applying a batch of log records to
the database it asserts in log0recv.c with:

InnoDB: Failing assertion: !page || (ibool)!!page_is_comp(page)==index->table->comp

How to repeat:
Just attempt to restart our database.

mysqld.log when trying to start the database

Attachment: mysql-error.txt (text/plain), 3.06 KiB.

Thank you for a problem report. Can you, please, send a resolved stack trace and explain
what happened before this assertion failure.

If the page in question is filled with zeroes, this could be a duplicate of Bug #23710.

This may be duplicate of http://bugs.mysql.com/bug.php?id=23710

Did mysqld originally crash VERY QUICKLY (in less than 10 seconds) after a mysqld
startup?

--Heikki

Ron,

can you post the entire .err log, also from before this latest crash?

--Heikki

Entire mysqld.log from server setup until after the crash

Attachment: mysqld.log (application/octet-stream, text), 436.12 KiB.

Unfortunately I didn't have any symbols available when I tried to run nm on mysqld_safe or
mysqld_multi.

I am working several hours away from this server, but learned that a number of other
machines where the server is housed just completely fell over about the time this error
occurred.

Upon trying to force recovery of the database one table was irretrievably corrupted, one
other had a recoverable error and others just had warnings.  Dumping the databases,
erasing the old tablespace, restarting MySQL, reloading the databases and recreating the
destroyed table seems to have gotten us back on-line.

I am currently packaging up the database and my.cnf.  A tar.gz was a little under 700MB. 
I just finished repackaging it as a tar.bz2 (532MiB) and will make that available to the
developers from our website.

I grabbed the database files but did not get around to analyzing them yet. This is not
likely to be a duplicate of Bug #23710, because all InnoDB tables are in a single
tablespace.

According to a private comment, the server may have been affected by power outage. I
would tend to blame the hardware or the operating system. fsync is often broken:

http://brad.livejournal.com/2116715.html?thread=10292331
http://peter-zaitsev.livejournal.com/12639.html

It would be very interesting if you could check the hardware and operating system with
the diskchecker.pl tool from Brad Fitzpatrick's log above.  I will have a look at this in
August, after my vacation.

Ron,
did you rule out hardware failure?

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".