A client's server is running MySQL 5.0. Last night the server automatically restarted to install Windows updates. After restarting, MySQL does not want to run any more. The MySQL log indicates that it shut down normally. Windows logs shows the service can't start because "Default storage engine (InnoDB) is not available". MySQL was running fine for years before this and nothing was recently changed.
Daily backups are made of the data, and the installation directory is still there.
How do I get the MySQL service running again?
EDIT: I just noticed the following in the server.err file in the data folder:
InnoDB: Error: log file .\ib_logfile0 is of different size 0 10485760 bytes
InnoDB: than specified in the .cnf file 0 25165824 bytes!
120112 5:16:30 [ERROR] Default storage engine (InnoDB) is not available
120112 5:16:30 [ERROR] Aborting
You should stop mysql server, delete log file and start it again. It should work afterwards. Of course, make a backup first. If it doesn't work, try fix from this link.
You can edit the .cnf, search for innodb_log_file_size parameter and set the size (in Megabytes) that match the size of the ib_logfile0.
C:\MySql\data> dir
24/10/2012 08:47 24.117.248 ib_logfile0
Megas = 24117248 / 1024 / 1024 = 23
innodb_log_file_size=23M
That try to start the service.
Well done Aleksandar Vučetić!
I have deleted these files from "mysql/data":
- ib_logfile0
- ib_logfile1
- ibdata1
and MySQL Service is started again.
MySQL log says:
InnoDB: The first specified data file .\ibdata1 did not exist:
InnoDB: a new database to be created!
140719 0:57:55 InnoDB: Setting file .\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
140719 0:57:55 InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 54 MB
InnoDB: Database physically writes the file full: wait...
140719 0:57:56 InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 54 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
140719 0:57:57 InnoDB: Started; log sequence number 0 0
In my case I had removed c:\windows\temp\myslql folder. I created "mysql" folder in temp again and viola it worked!
In my case, I could fix the issue by following commands. (On Ubuntu 20.04 (LTS) x64 DigitalOcean)
cd /var/lib/mysql
mkdir '#innodb_redo'
chown mysql:mysql '#innodb_redo'
systemctl restart mysql
I entered the server as root, but it should work as the same when you use sudo.
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
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]
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 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 found many similar question on Stackoverflow but didn't get the exact error solution.
My issue is when starting MySQL service on one of the Dedicated Centos 6.5 machine, I am getting error :
141018 05:13:46 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141018 5:13:47 [Warning] Can't create test file /var/lib/mysql/ip-184-168-73-83.lower-test
141018 5:13:47 [Warning] Can't create test file /var/lib/mysql/ip-184-168-73-83.lower-test
/usr/libexec/mysqld: Can't create/write to file '/tmp/ibkTWnhE' (Errcode: 28)
141018 5:13:48 InnoDB: Error: unable to create temporary file; errno: 28
141018 5:13:48 [ERROR] Plugin 'InnoDB' init function returned error.
141018 5:13:48 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141018 5:13:48 [ERROR] Can't start server : Bind on unix socket: No space left on device
141018 5:13:48 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
141018 5:13:48 [ERROR] Aborting
141018 5:13:48 [Note] /usr/libexec/mysqld: Shutdown complete
141018 05:13:48 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Here are free command status:
free -m
total used free shared buffers cached
Mem: 3743 3631 111 0 2705 21
-/+ buffers/cache: 905 2838
Swap: 2047 0 2047
This error also happens when your Database data is corrupt. You may fix this issue by moving your Db data files (ib_logfile0 and ib_logfile1) mentioned below to another location. ib_logfile0 and ib_logfile1 are system tablespace for the InnoDB infrastructure. These files contains several classes for information vital for InnoDB. You may read about these files here.
Before following below steps please keep a copy of files (ib_logfile0 and ib_logfile1) so you may restore your data in case it is lost:
Follow below steps:
Login to server via SSH with root access.
Navigate to /var/lib/mysql.
If you see files like, ib_logfile0 and ib_logfile1, rename or move them to some other folder.
Stop and start the MySQL service by running sudo service mysql stop and sudo service mysql start
These files will be recreated after you restart the server and the issue will be fixed hopefully.
Thanks
I have the same problems, this my solution:
Add more RAM to the server
Decrease the value of innodb-buffer-pool size in the config file:
sudo nano /etc/mysql/my.cnf
innodb_buffer_pool_size = 10M
After save /etc/mysql/my.cnf.
Restart mysql service:
sudo service mysql restart
exit
This is frequently occurred issue. Do following -
delete/move out these "aria_log_contro, ib_logfile0, ib_logfile1, ib_data1" files from location "..\xampp\mysql\data" and also from "..\xampp\mysql\backup".
stop and start apache server and mysql form xampp control panel
This should fix the issue; actually it worked for me.
NOTE: THIS IS GOING TO RESET THE DB IN MANY CASES BE VERY CAREFUL
Changing the values of innodb_buffer_pool_size and innodb_log_file_size didn't work for me.
Moving ib_logfile0 and ib_logfile1 files didn't help either.
What did help was:
> service mysql stop
Edit my.cfg and add innodb_force_recovery = 1
> service mysql start
> service mysql stop
Comment the innodb_force_recovery = 1 line.
> service mysql start
And voilá. (I should note that I have no idea if this involves any data loss or not)
Although late but putting answer here so that solution that helped me can help someone. I took following steps:
Added more RAM to sever
Decrease the value of innodb-buffer-pool size
Set innodb_log_file_size
Restart mysql
Example of addition to my.cnf:
innodb_buffer_pool_size = 10M
innodb_log_file_size = 1000M
After few unsuccess hours, i checked the disk space... and was full...
I was getting below mysql error log:-
[Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using Linux native AIO
InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
I found out there are two solutions which are:-
1)Set innodb_log_file_size equal to the actual size of the existing InnoDB log files.
To see what size of innoDB log allocated, login mysql and enter following cmd:-
SHOW GLOBAL VARIABLES LIKE 'innodb_log_file_size';
Expected result example:- 5242880
After that, insert that value in my.cnf:-
vi /etc/my.cnf
innodb_log_file_size =5242880
2)Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.This normally will be located at /var/lib/mysql. After start mysql, it create new innoDB log file and restore possible half-written data from the file of .ibd.
The expexted mysql log example:-
InnoDB: Database physically writes the file full: wait...
161216 9:58:54 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
161216 9:58:54 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
161216 9:58:54 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...
161216 9:58:54 InnoDB: Waiting for the background threads to start
161216 9:58:55 InnoDB: 5.5.50 started; log sequence number 1589772
161216 9:58:55 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
161216 9:58:55 [Note] - '0.0.0.0' resolves to '0.0.0.0';
161216 9:58:55 [Note] Server socket created on IP: '0.0.0.0'.
161216 9:58:55 [Note] Event Scheduler: Loaded 0 events
161216 9:58:55 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.50' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
References:-
JUSTIN KULESZA (2011). MySQL: Failed Registration of InnoDB as a Storage Engine. Available at: https://spin.atomicobject.com/2011/05/09/mysql-failed-registration-of-innodb-as-a-storage-engine/.
RolandoMySQLDBA (2014). MySQL my.cnf: innodb_log_file_size is missing. Available at: https://dba.stackexchange.com/questions/75688/mysql-my-cnf-innodb-log-file-size-is-missing/158325#158325
Changing the Number or Size of InnoDB Redo Log Files. Available at: http://dev.mysql.com/doc/refman/5.7/en/innodb-data-log-reconfiguration.html
Nothing was working with reinstalls, removes, and others (I had no data to keep, not a fix; more of a data destruction process, big caveat there):
1005 mysql_install_db
1007 /usr/bin/mysqld_safe --datadir='/var/lib/mysql
1008 /usr/bin/mysqld_safe --datadir='/var/lib/mysql' (^z)
1009 bg
1010 mysql
1011 mysql_secure_installation
1012 mysql
1013 mysql -p
And viola; actually usable database.
for me the solution was to change the config to add
innodb_use_native_aio = 0
in mysql config
Just move this log file (ib_logfile0) to some other place for safer side and start the mysql services it worked for me.
I also met the same issue when restore a backup set made via innobackupex to a new instance. Finally ,the root cause is innodb_log_file_size doesn't match original instance that take the backup, and fix steps by steps like below:
Get innodb_log_file_size value from oragin instance via below command:
mysql uroot -ppasswd -NBe "show global variables like 'innodb_log_file_size';"
Modify the /etc/my.cnf of new instance with last get value:
vim /etc/my.cnf
Restart mysqld via :
systemctl restart mysqld