Skip to main content

crashed innodb tables

persianwhois
Our mysql server crashed and for resolve problem we have removed "ibdata1" from /var/lib/mysql and restart mysql service. Now its start, but some website have problem to read database details. We have checked mysql log and we see many error like this: 2015-06-10 21:31:31 14939 [Warning] InnoDB: Cannot open table humble_tipsdb/qat_options from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/...eshooting.html How we should resolve this problem?

Comments

5 comments

Date Votes
  • cPanelMichael
    Hello, It's never a good idea to simply remove files with an expectation that it will resolve an issue. InnoDB corruption is outside our scope of support, but we do have a guide available at:
    0
  • cPanelRyanR
    Our mysql server crashed and for resolve problem we have removed "ibdata1" from /var/lib/mysql and restart mysql service. Now its start, but some website have problem to read database details. We have checked mysql log and we see many error like this: 2015-06-10 21:31:31 14939 [Warning] InnoDB: Cannot open table humble_tipsdb/qat_options from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/...eshooting.html How we should resolve this problem?

    Just to add to what Michael stated, I wanted to reiterate that removing ibdata1 is essentially the same as removing all of the data stored on InnoDB tables. You will not be able to access any of it, which is why I always recommend troubleshooting the InnoDB crash/corruption scenario in preference to re-generating a new ibdata1 file, unless you've got backups, in which case restoring from backups is always best. This seems to be a common misstep. One of the aspects that confuses people is that, after removing the ibdata1 file, they see that MySQL is again able to start. That's because it's not loading any of your InnoDB data. So if the crash was occurring due to an issue in one of the InnoDB tables, of course a clean slate ibdata1 file allow MySQL to start. It will not, however, load any of your existing InnoDB tables in that state. The InnoDB table files, unlike MyISAM table files, are not portable. They rely on the existence of metadata in the "data dictionary" (stored in the ibdata1 file) to correspond with them, in order to properly load them and verify their integrity. With that in mind, if you still have a copy of the original ibdata1 file, I would advise restoring that back into its place in /var/lib/mysql (or wherever you have your MySQL data directory configured), and troubleshooting the original crash issue from that point.
    0
  • James Bowlin
    Hello, It's never a good idea to simply remove files with an expectation that it will resolve an issue. InnoDB corruption is outside our scope of support, but we do have a guide available at:
    0
  • dalem
    OP posted "Our mysql server crashed and for resolve problem we have removed "ibdata1": has nothing to do with a software update of WHM/CPanel should read and take to heart
    0
  • cPanelMichael
    Wait so your software update of WHM/CPanel screws up MySQL and corrupts my databases and it's outside of the scope of your organization to provide support for that? Ok guess I will just cancel my WHM/CPanel licenses and contact a Web Host Panel Provider that is willing to support their products.

    Hello :) I sent a response to the following quote: Our mysql server crashed and for resolve problem we have removed "ibdata1" from /var/lib/mysql and restart mysql service.
    The cPanel update process should not cause InnoDB corruption. Did this happen on one of your servers? Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post