persianwhois

Well-Known Member
Apr 18, 2007
117
0
166
Mahallat
cPanel Access Level
Root Administrator
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?
 

cPanelRyanR

Member
Staff member
Jul 17, 2014
10
11
128
cPanel Access Level
Root Administrator
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.
 

James Bowlin

Member
Jun 18, 2015
10
0
1
Kansas
cPanel Access Level
Root Administrator
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:

https://forums.cpanel.net/threads/innodb-corruption-repair-guide.418722/

Thank you.
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.
 

dalem

Well-Known Member
PartnerNOC
Oct 24, 2003
2,977
155
368
SLC
cPanel Access Level
DataCenter Provider

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,213
363
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.