Force Wordpress to install in MyISAM instead of InnoDB

[GoWilkes]

I had a major problem last year with InnoDB, and had to completely disable it using:

innodb_force_recovery=5

No one has been able to track down the actual error, so instead I had to change everything to MyISAM.

Now I have a new account that wants to install Wordpress, but I keep getting errors because it tries to create tables in InnoDB.

Is there any way to modify Wordpress so that it creates tables in MyISAM instead?

 

[mtindor]

I had a major problem last year with InnoDB, and had to completely disable it using:

innodb_force_recovery=5

No one has been able to track down the actual error, so instead I had to change everything to MyISAM.

Now I have a new account that wants to install Wordpress, but I keep getting errors because it tries to create tables in InnoDB.

Is there any way to modify Wordpress so that it creates tables in MyISAM instead?

Is there any chance that you still have your default engine set to INNODB?

# mysql mysql
> show variables like 'default_storage%';

+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| default_storage_engine | MyISAM |
+------------------------+--------+

If you have your default_storage_engine set to InnoDB, that may be the issue. Might want to set it to MyISAM in /etc/my.cnf if it's not already set, using:

default-storage-engine=MyISAM

And then of course restart mysql

 

[GOT]

So, you've been running with force recovery in mode 5 all this time?

The right thing to do would be to try to make a dump of the database you have a problem with now, then take mysql out of recovery mode, drop the database and restore it from the dump.

 

[GoWilkes]

@mtindor, that worked! Thanks for the tip

@GOT, man, this has been a nightmare. I doubt that you'll remember this one, but 2 years ago (I think) I just woke up one day to find that MySQL was crashing repeatedly. Me and my server provider worked on it all day, and the only solution they could find was to implement force recovery. When they did that, though, it wiped out about half of the server's databases! And naturally, the only backup I had was 5 months old :-/

The best I could figure, the error originated in a table in my own site's database that I had named error_log. I was porting PHP errors to this table instead of a text file so that I could automatically ignore dupes. I came to the conclusion that it was the culprit because forcing recovery deleted that table and everything below it alphabetically :-O So I deleted that table from the backup, then after I restored the database I recreated it in MyISAM.

After that everything came up, but when I removed force recovery it all crashed again.

So then I went through all of the databases that I had backed up, manually changed the InnoDB tables to MyISAM, and restored them that way. The only ones I couldn't modify were the /mysql/ and /sys/ default databases.

Again, though, I removed force recovery and it all immediately crashed.

I spent literally months trying to fix it, before I eventually had to give up. None of us could ever figure out the issue. But since I've removed InnoDB from everything, it's not been a major issue anymore so it's easy to get pushed to the back burner.