Over the years innodb has caused me more trouble than anything else in the LAMP stack. MyISAM tables seem to work and repair without issue. Innodb seem to be endless trouble. Alas, clients need them so I have to make them work.
Today a mysql server crashed and wouldn’t restart. A few of the errors:
File operation call: 'read' returned OS error 71.
InnoDB: Operating system error number 2 in a file operation
among others. I won’t get into the causes – I’m sure 99% is due to poor shutdowns and other issues that are not really the fault of mysql (other than the lack of graceful failure whichh myisam seems to be so good at).
Here is a quick fix when under pressure – this won’t fix your problems if you have a single innodb table you need but if you have a mixed set of databases and tables this will get at least something working – which in my case was better than nothing.
Note that everything I’m saying to do is very bad form and practice. But if you have critical databases that need to be up it may help you out. As always, back everything up first just in case. You’ll have a back-up of a broken database but perhaps it will be a bit less broke than the version you have if the following goes wrong.
First find and move all databases with innodb tables to a temp directory :
find /var/lib/mysql -name "*.ibd" -print
# you'll see various files inding in .ibd - look at the directory they are in (the database name) and move that dir out of the mysql data directory
mv <database-dir> /var/lib/tmp_disable
Finally move the global .ibd and logs to the tmp directory:
mv /var/lib/mysql/ibdata1 /var/lib/mysql/ib_logfile* /var/lib/tmp_disable
mysql won’t like this and it’s not really a good idea. However your mysql server should at least start now. A new (empty) ibdata1 will be created. This will break a lot of things if your data is stored in this global datafile. However if you have each innodb table writing to its own ibd (by setting innodb_file_per_table in /etc/my.cnf) you might be ok.
Next, move each database back into /var/lib/mysql on-by-one, restarting mysql each time to see if it will still start. What to do with the database that is causing the problem? No easy answer to that unfortunately. I usually build a temporary mysql server in a VPS to work on it. At least your overall server will run while you are able to troubleshoot the problem database table(s).