Akonadi (KDE) crash: repair InnoDB data when MySQL can't start -
I run a small MySQL installation as part of my Akonadi (under KDE) installation. At some point some of my InnoDB data has recently become corrupted, I'm not sure, but it may be related to recent updates to some KDE packages. Right now I'm trying to get a set of recovery tools to compile (). Until then, I would try SO for some advice.
Unfortunately, MySQL will not run because of corruption, with the help of most of the help running online. Output of mysqld
:
Specifically, we have
140727 9: 22: 22] [note] Inodb: Log sequence number 13418196 And IBIDTA files do not match log sequence number 53487166 in 13418196 ib_logfiles! 140727 9: 22: 22 [Note] Inodb: The database was not normally closed! 140727 9: 00:22 [Note] InODB: Start the Crash Recovery. 140727 9: 22.22 [Note] Inodb: Reading table space information from IBD files ... 140727 9: 00:22 [Note] Inodb: Restoring Potentially Half-Written Data Pages 140727 9:22:22 [Note] Inodb: Repetition buffer ... 140727 9: 00:23 [error] mysqld signal found 11;
Fortunately, it seems that recently some of the ibd
files were modified, let me know what other information can help with this problem May be.
You still have less hanging fruits yet.
First of all, try to start MySQL with innodb_force_recovery = 4 (or 5, or 6). InnoDB crashes during the crash recovery process, so it is better to leave it. If it starts, then dump all databases and recreate the Indiabi table spaces.
Alternatively, you can check that you can repair the database and not reload without the dump as I have described in the post.
Only if MySQL does not start with innodb_force_recovery = 6, then you have to get records from the IBD files.
Anyway, I continue to develop the recovery toolkit. I have fixed some bugs related to recent MySQL versions and made it easy to use (there is no need to recompile, there is no reliance on unnecessary libraries)
Comments
Post a Comment