[SOLVED] mysql innodb corrupt, innodb_force_recovery 6 won't work

[wolvesled]

Originally Posted by raj

did you try innodb_force_recovery = 1 to 6 all six options in an increasing order of 1,2...6 or just tried 6 directly.
if you have not tried all 6 then i suggest you do that in increasing order and see if you can start mysqld service

Raj

I tried from 1 to 6, and not work, that's why I name this thread.

I examine the disk and found lot of bad sectors, and in my fsck process there is one of the ib_logfile has report damage.

[wolvesled]

any one can give me a list of ZCS 6.0 database structure include:

database name is zimbra, user is zimbra but all tables, I need it for using the recovery tool of innodb.

thanks in advance!

[wolvesled]

solved by the fsck.e3fs -cvf which is manually answering every question of the check tool. this really is the luck that just one of it is the ibdata file repaired, and I copy them it works.

conclusion, the other ways I have checked before moving to the last solution, which I saw all of them need a live connection to the mysql backend, as in this case there is no way of it, and no incremental backups there is no other mysql binlog in the zimbra system, so in case if hard corruption in the ibdata or ib_logfile not work even with innodb_force_recovery = 6, there is no way in zimbra 6.0.0 as tested.

so having a routine backup is a must!

[LMStone]

Originally Posted by wolvesled

solved by the fsck.e3fs -cvf which is manually answering every question of the check tool. this really is the luck that just one of it is the ibdata file repaired, and I copy them it works.

conclusion, the other ways I have checked before moving to the last solution, which I saw all of them need a live connection to the mysql backend, as in this case there is no way of it, and no incremental backups there is no other mysql binlog in the zimbra system, so in case if hard corruption in the ibdata or ib_logfile not work even with innodb_force_recovery = 6, there is no way in zimbra 6.0.0 as tested.

so having a routine backup is a must!

You can schedule a periodic MySQL dump if you like. We use a script called automysqlbackup.sh -- More info at: AutoMySQLBackup | Get AutoMySQLBackup at SourceForge.net

But it sounds like this wasn't a MySQL issue so much as a disk issue, yes?

Running hardware RAID10 with a battery-backed write-cache-equipped controller and a hot-spare disk drive is SOP for us, and even when the controllers fail (and they sometimes do), we have never lost data.

Even a moderately busy Zimbra mailbox server will see MySQL processing ~3,000 questions per second on average. That's not a load we like to see on marginal storage.

Virtualizing Zimbra will only add to the load on the storage system when the Zimbra VM competes for I/O with other VMs running on the host server.

I'm glad you were able to recover, but if it were me I'd be spending some time trying to find out why you got this disk corruption in the first instance -- so you can take steps to avoid this problem recurring in future.

Hope that helps,
Mark