MySQL Database Corruption on InnoDB



  • 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.



  • 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.



  • 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.