Unknown table engine 'InnoDB'

Submitted by securewebs on Wed, 06/10/2015 - 16:57 Pro Licensee

Unknown table engine 'InnoDB' ----- There are several sites now on a server that can't be backed up because of this error. Searching around I have read it might be a problem with the logfiles and that the fix might be to delete them and restart the mySQL. Is this a problem that is common enough to know the fix?

Status: 
Active

Comments

Submitted by andreychek on Wed, 06/10/2015 - 17:30

Howdy -- while I can't seem to find it at the moment, someone else had a similar problem recently, and removing the InnoDB related log files helped them out.

What I suggested in their case was to backup the entire /var/lib/mysql directory (you'd want to disable MySQL while doing that).

Then, move the "/var/lib/mysql/ib*log" files to another directory (perhaps /tmp).

After doing that, try restarting MySQL, and see if you're then able to perform your backups properly.

But again, before doing anything to your MySQL data, please make full backups of all your MySQL related data files with MySQL stopped :-)

Submitted by securewebs on Thu, 06/11/2015 - 08:35 Pro Licensee

I did as you suggested but no luck. Any account that is using a InnoDB table won't backup. In php if you click on a InnoDB table, or so I assume that is the common denominator, it says the table does not exist. On a mySQL command line you can't list the tables - it just goes off and never completes. Nor can you drop a table, same thing, it just spins the wheels forever. So InnoDB is suppose to be a high-reliability and high-performance storage engine. This version of mySQL is 5.1.73 so I would not have thought it to be any kind of default with this version of mySQL. Not really sure how it came to pass that InnoDB is being used. Anyway, looks like I have my work cut out for me. I am about to learn a lot more about mySQL than I ever wanted to know. In the end, I might have to restore from an old backup and try to manually incorporate the changes by looking into the current mySQL database. That will be an ugly job. They are all WordPress sites and they are working, just can't back them up.

Submitted by andreychek on Thu, 06/11/2015 - 10:18

Doing some Googling, I see other possible causes for the problem you're experiencing.

One such post mentions they ran into this issue with /tmp was full. You can determine if that's occurring by running "df -h".

Also, there could potentially be other errors showing up in the MySQL error logs in /var/log -- it may be worth taking a look there to see if any problems are showing up there.

Submitted by securewebs on Thu, 06/11/2015 - 11:50 Pro Licensee

Hi: Yes thanks. I did empty the /tmp folder for that reason and have snooped all around with df -h deleting the virtualmin access logs (hope that is OK) as some where very large. And I did run out of room on this server twice in the last few months which stopped mySQL from starting. Perhaps that was where the damage was done. That is one reason we are shuffling about servers and licenses. A server with 50 virtual servers is not so big but it is big enough for me. I would rather have a few extra servers than even having a 100 on one machine, just being a bit cautious. Love the control panel if I have not said it already. I will keep slogging on. There are just a few sites that will prove a problem to migrate to some new CentOS 7.x machines we will be building. In a month or two I expect to have 5 or 6 CentOS 7 machines and perhaps no 6.x machines. I still very much like 6.x and more comfortable with it but I want to setup server I don't have to change again for years (I hope). Thanks for the suggestions. If I am ever able to fix it I will let you know what I discovered was the fix.

The biggest logfile by the way is a surprise, I think it was mailxxx.log and the second biggest might have been securexxx.log. Considering we don't use the server for email I wonder how that log file exists let alone why it is the biggest. I think it grew to about 18GB and was the final straw on running the server out of room. Any thoughts on how to either track less details or stop the logfile altogether?

Submitted by andreychek on Thu, 06/11/2015 - 12:01

We'd be happy to help with those log issues -- that sounds like a different problem there, and may be related to logrotate. Or something else, I'm not quite sure yet :-)

Could you open a separate support request for that issue?

In that request, let us know the time/date of the first entry in that large log file.

Also let us know if you see any recurring messages/errors in the logs.

Thanks!