Summary: | dev-db/mysql-5.5.28 - InnoDB: Assertion failure in thread 140230384047936 in file trx0rseg.c line 337 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | Current packages | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugs.mysql.com/bug.php?id=67528 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
my.cnf |
Description
Martin von Gagern
2012-11-08 12:49:49 UTC
After downgrading to mysql 5.1, the server started correctly, and a mysqldump of all tables succeeded as well. So I take it my data is intact, at least for 5.1. I've upgraded again, moved my data directory, configured mysql like a fresh install, and am currently playing back my dump. That error looks a lot like http://bugs.mysql.com/bug.php?id=57387. Can you please post your my.cnf and /etc/conf.d/mysql? Created attachment 328828 [details] my.cnf (In reply to comment #2) > That error looks a lot like http://bugs.mysql.com/bug.php?id=57387. The failed assertion mentioned there looks the same. But that assertion was for the case where innodb_data_file_path did not contain autoextend. On my system I have innodb_data_file_path='ibdata1:10M:autoextend:max:128M'. > Can you please post your my.cnf and /etc/conf.d/mysql? Non-comment lines from /etc/conf.d/mysql: MY_CNF="/etc/mysql/my.cnf" MY_ARGS="" STARTUP_TIMEOUT="900" STARTUP_EARLY_TIMEOUT="1000" STOP_TIMEOUT=120 [ "${SVCNAME}" != mysql ] && rc_provide="!mysql" return 0 my.cnf attached. The switch from language to lc_messages helped avoid an error message from 5.5 (when starting the daemon directly from the command line), but caused 5.1 to fail to start. So I switched between both alternatives there. The most notable change to my my.cnf from the distribution default is perhaps the fact that I disabled the binary log. Not sure whether that's got anything to do with anything. (In reply to comment #3) > Created attachment 328828 [details] > my.cnf > > (In reply to comment #2) > > That error looks a lot like http://bugs.mysql.com/bug.php?id=57387. > > The failed assertion mentioned there looks the same. But that assertion was > for the case where innodb_data_file_path did not contain autoextend. On my > system I have innodb_data_file_path='ibdata1:10M:autoextend:max:128M'. > The bug was for when the main tablespace hit the maximum because it inflated another 8MB. What size is your ibdata1 file? Does the assertion still happen if you increase the max to like 256M? (In reply to comment #4) > (In reply to comment #3) > > Created attachment 328828 [details] > > my.cnf > > > > (In reply to comment #2) > > > That error looks a lot like http://bugs.mysql.com/bug.php?id=57387. > > > > The failed assertion mentioned there looks the same. But that assertion was > > for the case where innodb_data_file_path did not contain autoextend. On my > > system I have innodb_data_file_path='ibdata1:10M:autoextend:max:128M'. > > > The bug was for when the main tablespace hit the maximum because it inflated > another 8MB. > > What size is your ibdata1 file? 128MiB exactly. Which seems kind of large, seeing as in the database restored from my dump, that same file is only 19M. But I must confess, I'm not really sure what that file contains. Does that file contain all the InnoDB tables from this MySQL instance? > Does the assertion still happen if you increase the max to like 256M? No, in that case, mysqld starts and ibdata1 grows to 142606336 bytes. mysql_upgrade succeeded, and the size stays as it is. Trying to find out what this file is all about, I found http://stackoverflow.com/q/3456159/1468366 . Sounds like reclaiming space from that file is a real problem, and perhaps I'd be better off with my newly restored dump instead of the old cruft. Perhaps I should even consider using innodb_file_per_table. What I find really disturbing is the discrepancy between this observed behaviour and the one described in http://dev.mysql.com/doc/refman/5.5/en/full-disk.html. From the manual, I'd have expected proper error messages whenever some resource, be it disk or tablespace, gets exhausted. The fact that a full disc should be handled more gracefully than a reached configuration limit seems really really strange. And a failed assertion together with a backtrace and a SIGABRT really feel inappropriate for such a configuration issue. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > The bug was for when the main tablespace hit the maximum because it inflated > > another 8MB. > > > > What size is your ibdata1 file? > > 128MiB exactly. Which seems kind of large, seeing as in the database > restored from my dump, that same file is only 19M. But I must confess, I'm > not really sure what that file contains. Does that file contain all the > InnoDB tables from this MySQL instance? The thing about Innodb is the main file never shrinks unless you dump the entire system and reload from scratch. innodb_file_per_table will help keep the size down. > > > Does the assertion still happen if you increase the max to like 256M? > > No, in that case, mysqld starts and ibdata1 grows to 142606336 bytes. > mysql_upgrade succeeded, and the size stays as it is. > > Trying to find out what this file is all about, I found > http://stackoverflow.com/q/3456159/1468366 . Sounds like reclaiming space > from that file is a real problem, and perhaps I'd be better off with my > newly restored dump instead of the old cruft. Perhaps I should even consider > using innodb_file_per_table. Exactly. > > What I find really disturbing is the discrepancy between this observed > behaviour and the one described in > http://dev.mysql.com/doc/refman/5.5/en/full-disk.html. From the manual, I'd > have expected proper error messages whenever some resource, be it disk or > tablespace, gets exhausted. The fact that a full disc should be handled more > gracefully than a reached configuration limit seems really really strange. > And a failed assertion together with a backtrace and a SIGABRT really feel > inappropriate for such a configuration issue. This is really an InnoDB issue which needs to be taken upstream. It should fail more gracefully. I expect it has to do with initialization failure going from newly created or updating an old tablespace. (In reply to comment #6) > This is really an InnoDB issue which needs to be taken upstream. It should > fail more gracefully. Reported upstream as http://bugs.mysql.com/bug.php?id=67528 (In reply to comment #7) > (In reply to comment #6) > > This is really an InnoDB issue which needs to be taken upstream. It should > > fail more gracefully. > > Reported upstream as http://bugs.mysql.com/bug.php?id=67528 Can you please test with mysql-5.6.10 as requested in the upstream bug report? (In reply to comment #8) > Can you please test with mysql-5.6.10 as requested in the upstream bug > report? I'm still waiting for an ebuild for mysql-5.6. So far, 5.5.30 is the latest in portage. (In reply to comment #9) > (In reply to comment #8) > > Can you please test with mysql-5.6.10 as requested in the upstream bug > > report? > > I'm still waiting for an ebuild for mysql-5.6. So far, 5.5.30 is the latest > in portage. Please test the ebuild in the mysql overlay[1]. [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git Marking as TEST-REQUEST as no feedback has been given for over a year |