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

Bug #29221	InnoDB asserts in log0recv.c when
Submitted:	19 Jun 2007 19:32	Modified:	13 Sep 2007 12:40
Reporter:	Ron Parker	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.0.22	OS:	Linux (RHEL 5)
Assigned to:	Assigned Account	CPU Architecture:	Any

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