I run a small MySQL installation as part of my Akonadi (under KDE) installation. At some point recently some of my InnoDB data has become corrupted. I'm not sure, but it may be related to a recent update of some KDE packages. Right now I'm trying to get a set of recovery tools to compile (https://launchpad.net/percona-data-recovery-tool-for-innodb).
Until then, figured I'd try SO for some advice.
Unfortunately, MySQL will not run due to the corruption, most of the help I've found online relies on it to be running. Output of mysqld: http://paste.kde.org/prkw3di6d
In particular, we have
140727 9:00:22 [Note] InnoDB: The log sequence numbers 13418196 and 13418196 in ibdata files do not match the log sequence number 53487166 in the ib_logfiles!
140727 9:00:22 [Note] InnoDB: Database was not shutdown normally!
140727 9:00:22 [Note] InnoDB: Starting crash recovery.
140727 9:00:22 [Note] InnoDB: Reading tablespace information from the .ibd files...
140727 9:00:22 [Note] InnoDB: Restoring possible half-written data pages
140727 9:00:22 [Note] InnoDB: from the doublewrite buffer...
140727 9:00:23 [ERROR] mysqld got signal 11 ;
Fortunately, it seems that only a few of the ibd files were modified recently. Let me know what other information could help with this issue.
You haven't exhausted low-hanging fruits yet.
First, try to start MySQL with innodb_force_recovery=4 (or 5, or 6). InnoDB crashes during crash recovery process, so it's better to skip it.
If it starts take a dump of all databases and re-create InnoDB table spaces.
Optionally you could check if you can repair the database without dump&reload as I described in "Repair Corrupted InnoDB Table with Corruption in Secondary Index Edit" post.
Only if MySQL doesn't start with innodb_force_recovery=6 then you need to fetch records from ibd files.
By the way, I continue development of the recovery toolkit in https://launchpad.net/undrop-for-innodb . I fixed some bugs related to recent MySQL versions and made it easier to use (no need to recompile, no dependencies on unneeded libraries)
Related
I recently updated my XAMPP version to be able to use PHP 7.
I had no problems migrating, so I copied the whole directory to my notebook to work on it.
There the MySQL service always crashed on startup. Having returned to my PC today I had to realize that MySQL won't start on my PC anymore.
2017-05-14 19:02:58 8200 [Note] InnoDB: The log sequence numbers 2453615 and 2453615 in ibdata files do not match the log sequence number 2453645 in the ib_logfiles!
2017-05-14 19:02:58 8200 [Note] InnoDB: Database was not shutdown normally!
2017-05-14 19:02:58 8200 [Note] InnoDB: Starting crash recovery.
2017-05-14 19:02:58 8200 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-05-14 19:02:58 8200 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace bnw/bnwv1_games uses space ID: 29 at filepath: .\bnw\bnwv1_games.ibd. Cannot open tablespace phpmyadmin/pma__export_templates which uses space ID: 29 at filepath: .\phpmyadmin\pma__export_templates.ibd
This should be the interesting part from the error log. A message later it suggests to set innodb_force_recovery > 0, but then it only complains about missing db.MYI (and also MYD and also for server, user, event after creating empty files).
Since the ib_logfiles log sequence number increases by 10 on every attempted start and I'm quite sure there is no corrupted data in the DB, I think it would be enough to manually reset it. How can I do this?
Edit: Complete error log (from another start): https://pastebin.com/T7GRgK4v
Probably this issue is with the below line in [mysqld] section which somehow commented-out/removed from my.ini file:
key_buffer = 16M
After commenting this out this line will be:
#key_buffer = 16M
Please first check your Windows Event Viewer for more clues to the errors in XAMPP Control Panel.
Two issues...
InnoDB had some trouble. You changed innodb_force_recovery? And you changed it back, I hope.
MyISAM is having some kind of trouble with a table? Then do CHECK TABLE on the table in question, then do REPAIR TABLE on that table. That should fix and/or rebuild the .MYI (which contains the indexes for one MyISAM table).
Apologies I am quite new at this, so the easier the better! I need to rescue a wordpress database from a corrupted MAMP installation.
This is the error I am receiving in the MySQL Log when I try and open MAMP:
https://codeshare.io/GqPykx
Thanks for any assistance!!
K
You could start by applying the specified methods to restore to a known state. If you're lucky you have permissions problem you just need to fix on the table storage files, if you're unlucky you should restore from your backup disk.
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 ./olivia/wp_term_taxonomy.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.
My MySQL Server wont start anymore on MAMP. The solutions I found online said, that I should first quit MAMP, quit the MYSQL process, and start MAMP again.
But there is no MySQL process running in my situation, so this didn't work. Do you have any idea, what else could be the process?
You can find my error log here:
2017-01-20 21:40:03 7fff79bb0000 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 ./yunityproject_wordpress/wp_comments.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. 170120 21:40:04 mysqld_safe mysqld
from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
Just had this issue. Turns out a mysql.pid file was missing from the mamp\tmp\mysql\ folder. uninstalled, reinstalled and everything works. just make sure you delete the old mamp folder.
[coincidence? my mamp-pro license just expired and then this issue happened]
Our server has been running mysql just fine for over a year. I ran a set of sql script to build a rather large database and in the middle of those scripts, I started getting errors that I had lost connection. Nobody did anything else happened as far as we know. When I tried to log in to mysql, I got:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
When I try to restart mysql, I get:
# sudo service mysql restart
stop: Unknown instance:
start: Job failed to start
The error.log shows:
130212 9:37:51 [Note] Plugin 'FEDERATED' is disabled.
130212 9:37:51 InnoDB: The InnoDB memory heap is disabled
130212 9:37:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130212 9:37:51 InnoDB: Compressed tables use zlib 1.2.7
130212 9:37:51 InnoDB: Using Linux native AIO
130212 9:37:51 InnoDB: Initializing buffer pool, size = 10.0G
130212 9:37:51 InnoDB: Completed initialization of buffer pool
130212 9:37:51 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2186809272046
130212 9:37:51 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 2186814514688
InnoDB: Doing recovery: scanned up to log sequence number 2186816162838
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 27964 row operations to undo
InnoDB: Trx id counter is 18834200
130212 9:37:51 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4424818.
InnoDB: You may have to recover from a backup.
130212 9:37:51 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 058425e20043847200356a3f003e3720000001fd2807769645bf00000000000000000000000000ef31a083ca0000000031980005000003c8000$
InnoDB: End of page dump
18 130212 9:37:51 InnoDB: Page checksum 1501194131, prior-to-4.0.14-form checksum 441953139
InnoDB: stored checksum 92546530, prior-to-4.0.14-form stored checksum 1240647222
InnoDB: Page lsn 509 671577750, low 4 bytes of lsn at page end 441447404
InnoDB: Page number (if stored to page already) 4424818,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 1096815
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4424818.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130212 9:37:51 InnoDB: Assertion failure in thread 140114781574912 in file buf0buf.c line 3603
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:37:51 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346681 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f72aa2435b9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7f72aa12c548]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f72a8c8dcb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f72a82f6425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f72a82f9b8b]
/usr/sbin/mysqld(+0x605429)[0x7f72aa32d429]
/usr/sbin/mysqld(+0x631b69)[0x7f72aa359b69]
/usr/sbin/mysqld(+0x5c20a8)[0x7f72aa2ea0a8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f72a8c85e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f72a83b3cbd]
I cannot find anything running for mysql including any sockets.
I am taking over for a previous SysAdmin and am fairly new to linux and MySql. We've got to get this system back online soon. Please help.
Have you tried adding the following line to your /etc/mysql/my.cnf and then restarting the server?
[mysqld]
innodb_force_recovery = 4
To add to #elico3000 you will now need to dump your corrupt table(s) and Data to repair the innodb fs. There are a number of ways to do this. You can read through the logs to determine the point of failure and possible tablenames, then dump and recreate those specific tables. Or you can dump the entire MySQL DB and all schemas using a single command, but that will take some time depending on how big your DB. Either way once you have addressed the corrupt table(s) you can set the innodb_force option to 0 and restart mysqld_safe.
Here is a good tutorial on recovery options for both MyISAM and InnoDB MySQL instances and covers a few options. It is far easier to point you here, than regurgitate the commands and concepts again in this answer.
Good luck and come back to ask more pointed questions once you have tried one of the options. There are probably more tutorials out there, but I have used this in Development to rebuild my Dev DB and it has plenty of information.
Look here
Hi mistakenly I have deleted my MySQL database from Windos XP based PC (this database was used to host a Wiki service using Xampp package). Now I am trying to restore the data so that I can atleast retrieve the TEXT entered in the respective table of Mediawiki package.
After deletion I tried to recover the data using Minitool data recovery software and was able to recover the main schema folder containing .frm files, ib_logfile0, ib_logfile1 and ibdata1 (which was stored under C>xampp>mysql>data).
Now I am trying to restore the database so that I can take a SQL dump and use it accordingly. I have consulted some previous suggestions provided by the experts. Below are the links -
Restoring MySQL InnoDB files on Windows
Stackoverflow answers
But these did not help me very much, not sure what exactly I am missing from the instructions. At the end I was unable to start MySQL service and it failed with the below errors in log -
120823 12:17:04 [Note] Plugin 'FEDERATED' is disabled.
120823 12:17:04 InnoDB: The InnoDB memory heap is disabled
120823 12:17:04 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120823 12:17:04 InnoDB: Compressed tables use zlib 1.2.3
120823 12:17:04 InnoDB: Initializing buffer pool, size = 16.0M
120823 12:17:04 InnoDB: Completed initialization of buffer pool
120823 12:17:04 InnoDB: highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html
120823 12:17:04 [ERROR] Plugin 'InnoDB' init function returned error.
120823 12:17:04 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823 12:17:04 [ERROR] Unknown/unsupported storage engine: InnoDB
120823 12:17:04 [ERROR] Aborting
Any help to recover from this situation will be highly appreciated. I am willing to provide some more data if required. [MySQL Server Version 5.5, xampp-win32-1.8.0-VC9]
Oh God finally it's solved :)
Actually I am a novice that's why I could not solve this quickly. Here is the workflow I followed.
I installed a fresh copy of MySQL server. Run Wizard config for transactional database.
I stopped MySQL from Services.msc
Then overwrote the ib* and *frm files (under the schema folder) in C/programdata/mysql/mysql server 5.5/data folder
Updated the my.ini in C/apps/mysql with the innodb_log_file_size=<actual size of iblogfile0>
ran the command mysqld --defaults-file="C:/apps/mysql/my.ini" --standalone --console --innodb_force_recovery=6
once the above completed closed cmd.exe
restarted MySQL service
Opened MySQL workbench and took a dump
Sorry to confuse you all. Thanks again. Let me know if anybody requires any clarity for the above steps.