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).
Related
I know this might seem a duplicate, but I am struggling.
I managed to start and run Apache and MySQL for one session using MAMP. Come to it again, MySQL will not start.
I have tried various answers on Stack. Reinstalling / moving directories / making sure things are update. The one thing I haven't done, is renaming the 'ib_logfile' - because they are not there!
Anyone have any suggestions?
2017-09-23 20:44:46 7fffa5a753c0 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 ./mysql/slave_worker_info.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.
170923 20:44:46 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
So far I got it working - I change the permissions for the Mysql folder in Mamp to read and write and all the containing folders and it seems to work.
go to /Applications/MAMP/tmp/mysql/ and add new file mysql.pid
restart mamp
I recently attempted to upgrade a MySQL 5.1 server to 5.7. When the server wouldn't start, I discovered you have to export the data first, else do numerous upgrades (the binaries for which aren't available anymore), so I rolled back to 5.1 to do an export.
The problem is, back on 5.1, InnoDB will no longer register. In the error log i get:
InnoDB: Error: log file ./ib_logfile0 is of different size 0 50331648 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
160822 17:05:12 [ERROR] Plugin 'InnoDB' init function returned error.
160822 17:05:12 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
As a workaround I set innodb_log_file_size=50331648 in my.cnf. Another restart and:
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.1/en/error-creating-innodb.html
Reading that links it suggests to delete all files created by InnoDB: all ibdata files and all ib_logfile files. I have a 120 GB ibdata file that I most certainly do not intend to delete, so this is a non-starter. I did try renaming the logfiles though and the server still wouldn't come up.
Any pointers from here?
Edit: I also tried renaming the iblog files. That causes another error where mysql suggests setting innodb_force_recovery=6. Doing that causes these errors:
160823 12:17:32 InnoDB: Page checksum 271832187, prior-to-4.0.14-form checksum 315921779
InnoDB: stored checksum 401867329, prior-to-4.0.14-form stored checksum 401867329
InnoDB: Page lsn 96 3891045697, low 4 bytes of lsn at page end 3891045697
InnoDB: Page number (if stored to page already) 966706,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 966706.
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 966707.
InnoDB: You may have to recover from a backup.
160823 12:17:32 InnoDB: Page dump in ascii and hex (16384 bytes):
I encounter the similar problem just now. I run both MySQL 5.1 and 5.7 in the same server.
With MySQL 5.1, the default innodb_log_file_size is 5m.
mysql> show variables like 'innodb_log_file_size';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| innodb_log_file_size | 5242880 |
+----------------------+---------+
1 row in set (0.00 sec)
While MySQL 5.7, the default innodb_log_file_size is 48m.
mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name | Value |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+
1 row in set (0.01 sec)
When upgrade a MySQL 5.1 server to 5.7 and then downgrade to 5.1, the ib_logfile0/1 file was changed in a magic way. The checkpoint of log file cannot be identified. So innodb cannot execute a normal recovery using the log files. I didn't make a deep research so i can't give a detailed explanation.
Solution
Backup datafile and restart MySQL
mv ibdata1 ibdata1.bak
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak
service mysqld restart
Modify my.cnf file, add the following line
innodb_force_recovery=6
Restore datafile and restart again
mv ibdata1.bak ibdata1
service mysqld restart
Now you will see MySQL start successfully. Ibdata1 may not work properly. You can backup your application data using mysqldump. Then remove the recovery line in my.cnf file. Remove ibdata and logfile as well. Restart MySQL and Import your backup.
A little complex, but these help me.
Faults
As the redo log file was recreated, a little piece of log cannot be redo.
Do not delete ibdata*. That is where all the data is!
By now, the log files should not matter. So, there are a couple of ways to deal with the 'error'.
Get back the old my.cnf. If that is not practical, at least set
innodb_log_file_size = 50331648
(The change to the log file is a bit tricky. Apparently 5.7 increased it to the new default of 48MB without a problem. However, 5.1 does not have the code to dynamically change the file size.)
Another approach is to delete (or move aside) the iblog* files.
I have been working on a problem for a few days now. Our local mediawiki page that sits on our box account, destroyed itself and we've been working to get it online. Using XAMPP Control Panel v3.2.1, the errors were numerous so we decided to update XAMPP (v3.2.2) and move the 'htdocs' and 'mysql/data' files over to the new data base.
First error:
9:50:21 AM [mysql] Attempting to start MySQL app...
9:50:22 AM [mysql] Status change detected: running
9:50:22 AM [mysql] Status change detected: stopped
9:50:22 AM [mysql] Error: MySQL shutdown unexpectedly.
9:50:22 AM [mysql] This may be due to a blocked port, missing dependencies,
9:50:22 AM [mysql] improper privileges, a crash, or a shutdown by another method.
9:50:22 AM [mysql] Press the Logs button to view error logs and check
9:50:22 AM [mysql] the Windows Event Viewer for more clues
9:50:22 AM [mysql] If you need more help, copy and post this
9:50:22 AM [mysql] entire log window on the forums
As it says, I then went to the logs and found this:
2015-11-20 09:50:22 11f8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-11-20 9:50:22 4600 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-20 9:50:22 4600 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-20 9:50:22 4600 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-11-20 9:50:22 4600 [Note] InnoDB: Memory barrier is not used
2015-11-20 9:50:22 4600 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-11-20 9:50:22 4600 [Note] InnoDB: Not using CPU crc32 instructions
2015-11-20 9:50:22 4600 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-11-20 9:50:22 4600 [Note] InnoDB: Completed initialization of buffer pool
2015-11-20 9:50:22 4600 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-20 9:50:22 4600 [Note] InnoDB: The log sequence numbers 1665234 and 1665234 in ibdata files do not match the log sequence number 50125498 in the ib_logfiles!
2015-11-20 9:50:22 4600 [Note] InnoDB: Database was not shutdown normally!
2015-11-20 9:50:22 4600 [Note] InnoDB: Starting crash recovery.
2015-11-20 9:50:22 4600 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: .\phpmyadmin\pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: .\wiki\archive.ibd
InnoDB: Error: could not open single-table tablespace file .\wiki\archive.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.
Now this looks like a standard error that I've seen with many different suggestions throughout the web on how to fix it. I will go over them briefly.
The first thing I tried was to follow the suggestions in the log.
The were no permission problems
It is not clear if I need the table or not, OR whether to get rid of phpmyadmin/pma__tracking or archive.ibd. When I got rid of the archive.ibd, the error just past on to another .ibd file.
'innodb_force_recovery=1' was added to my.cnf and this cause a bunch of errors.
The next thing I noticed is that when we built the new database, I got this error in my phpMyAdmin (localhost/phpMyAdmin):
phpMyAdmin error
I'm not sure if this is causing all of my problems or not. I found that people were saying to switch a password to =''. This error might be happening because I'm entering old data folders in a new database. I'm not sure.
The first suggestion on the web was to remove the following files from
\mysql\data:
innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd
The 2nd:
I've tried removing 'ibdata1'
None of these have worked.
I had the same problem. I tried all the solution others has proposed, and unfortunately nothing worked.
After spending hours on searching for the solution in Google I finally found this
Open my.ini (my.cnf on linux-based systems and Mac)
Look for [mysqld]
Just below [mysqld] insert innodb_force_recovery = 1
Start MySQL Service
Stop MySQL Service
Remove the line from my.ini (innodb_force_recovery = 1)
Start MySQL Service
Worked perfect in my case.
I hope this will solve your problem.
I got the same error. These are the steps I followed.
Took the backup of \xampp\mysql\data
Removed all the files and folders from data folder except mysql
Quit and started the XAMPP again.
Move the databases from data folder one by one.
try to rename /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0 to /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0.bkp
and /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1 to /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1.bkp
Solution is for MAC 10.11.3 El Captian
Go to /Applications/XAMPP/xamppfiles/var/mysql/
Delete all random files (except the actual database folders)
Restart Apache and MySQL.
This worked for me.
To use the above (Nesar solution) in MAMP (version >= 4), you must first copy the my.cnf file that is inside MAMP/tmp/mysql to the MAMP/conf folder. Only then will it work.
I had a similar problem with Mamp Pro. For me it turned out the correct .idb-files were not located at "Applications/Mamp...". So taking a closer look at the error-log it showed me the files were located at "/Library/Application Support/appsolute/MAMP PRO/db". As I had problems with a database I wasn't using anymore, I just tried to delete the corresponding folder and it worked out. The next step would have been to delete the files already mentioned by the author.
innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd
But as mentioned deleting the databasefolder worked out great.
Tgr's answer looks appropriate. The message about permissions etc. is a generic one; the actual error message is
2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: .\phpmyadmin\pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: .\wiki\archive.ibd
Your wiki database and phpmyadmin database somehow ended up with the same tablespace ID. Each would work fine if the other wasn't present; as it is now, you'll have to renumber one of them somehow.
"Attempted to open a previously opened tablespace." -- That smells like one of these:
There are two copies of MySQL and both are trying to run.
Windows failed to release an 'open' on one of MySQL's files. I used to see that problem. It was cured by rebooting Windows; later by upgrading Windows.
Another solution for the issue discribed above for MAMP Pro, as I found impossible to edit my.cnf properly :
When InnoDB is crashing, spot in the error message the DB that is causing trouble. Here it is phpmyadmin/pma__tracking so the table is the one with the pma_ extension.
Then go to /Library/Application Support/appsolute/MAMP PRO/db/mysql and remove the folder named after the problem causing DB.
Restart your MAMP server.
Once you restarted with success, you can stop servers again, put back the DB folder where it belongs and start the servers again. Everything should be fine again.
I had the same problem, after use recovery database structure ( http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html )
I remove the archive.ibm file and start mysql.
then create archive table in database.
if someone has problems with any of their corrupt tables, this may be a possible solution to their problem, in my case I had the backup of my database so just delete the tables that are the files .ibd then restart MAMP PRO and mysql started correctly. A database backup must be taken into account. hope this helps someone and doesn't waste a lot of time. regards
after 4 hours i got solution without loos any data, please use below to resolve your issue
I had the same problem. I tried all the solution others has proposed, and unfortunately nothing worked.
After spending hours on searching for the solution in Google I finally found this
Open my.ini (my.cnf on linux centos /etc/my.cnf.d/server.cnf)
Look for [mysqld]
Just below [mysqld] insert innodb_force_recovery = 1
Start MySQL Service
Stop MySQL Service
Remove the line from my.ini (innodb_force_recovery = 1)
Start MySQL Service
Worked perfect in my case.
I hope this will solve your problem.
I recently upgraded XAMPP, and (stupidly, probably) simply copied my old mysql/data folder into the new installation. I'm not sure what version of MySQL I was running before, but it was probably 5.1. The new version is 5.6. Whenever I start MySQL now, I get this error:
2014-11-05 23:31:04 8784 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace db_name/table_name uses space ID: 2 at filepath: .\db_name\table_name.ibd. Cannot open tablespace mysql/innodb_index_stats which uses space ID: 2 at filepath: .\mysql\innodb_index_stats.ibd
InnoDB: Error: could not open single-table tablespace file .\mysql\innodb_index_stats.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.
I know from this question and others that deleting the ibdata1 and ib_logfile0 files temporarily solves this problem, but I need to do it each time I start XAMPP / MySQL. Is there a way to fix this problem permanently?
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)