MySQL Database Corruption on InnoDB

scottalanmiller

Got this in the logs. Just starting to work on it...

2019-04-30 20:50:39 3990 [Note] InnoDB: Reading tablespace information from the .ibd files...
2019-04-30 20:50:39 3990 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace ca_prod_2018/wp_1_contactformmaker_blocked uses space ID: 592 at filepath: ./ca_prod_2018/wp_1_contactformmaker_blocked.ibd. Cannot open tablespace ca_stag2/wp_1_contactformmaker_blocked which uses space ID: 592 at filepath: ./ca_stag2/wp_1_contactformmaker_blocked.ibd
2019-04-30 20:50:39 7ff840bd8720  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./ca_stag2/wp_1_contactformmaker_blocked.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

Mostly putting here so that I have a working space for tracking the process. Off to see what we have to work with. It's my first time on this box.

scottalanmiller

So the file that it says that it cannot open, ca_stag2/wp_1_contactformmaker_blocked.ibd is definitely there and permissions on it are correct.

scottalanmiller

So, easy fix, the ca_stag2 was a staging DB that was not needed and was not current. The whole thing appears to have corrupted. So I simply "moved" that entire directory to /tmp (just in case I had to put it back) and then MySQL could fire up.