Plugin innodb init function returned error mariadb

Arch Linux

You are not logged in.

#1 2013-03-25 23:29:10

[SOLVED] Cannot start mysqld after switching to MariaDB

I just switched to MariaDB as recommended.
After installing MariaDB and running

, I get this error message:

Last edited by lonaowna (2013-03-26 01:23:20)

#2 2013-03-25 23:39:28

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Hi ! I come here because I have a trouble since the last update of Mysqld :
I cannot start the daemon with

I have these problems when i look in journalctl -xn :

When I try with mysqld, I have

And when I look in /var/lib/mysql/server.err I have these lines

When I try mysqld_safe, here is what I get

Resolution
===== It’s a good thing to make a post :
It allows me to order my ideas and I find the solution here http://serverfault.com/questions/104014 … erent-size

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

Last edited by shox (2013-03-25 23:51:43)

#3 2013-03-26 00:15:06

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Merging with the solved Mysqld thread.

Registered Linux User #482438

#4 2013-03-26 01:22:47

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Thanks! I almost used the same solution: I had to delete

#5 2013-03-27 10:14:33

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I’ve tried both solutions but I’m still unable to start the mysqld.service
What else can I try?

code for systemctl status mysqld.service

code for journalctl -xn

code for mysql_upgrade

Last edited by Box0 (2013-03-27 10:26:32)

#6 2013-03-27 10:50:09

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

As far as I know, you have to get mysql_upgrade to work. Did you use the -p option? If so, did you get the password typed correctly?

«It is very difficult to educate the educated.»

#7 2013-03-27 12:03:38

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I get the output posted in my previous message after running both mysql_upgrade and mysql_upgrade -p.

I don’t even reach the step where it asks to insert your password.

#8 2013-06-23 13:29:55

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Hello,
I have the same problem, Tried all the solutions but didn worked for me.
@Box0: Did you able to find a solution for this ?

#9 2013-07-03 20:55:55

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Bumping this, as I think solving it will fix my Amarok crashing problem. I’ve only just now got around to switching from the outdated mysql to MariaDB. I tried the solutions here and none of them work.

Here’s my journalctl -xn output:

and the systemctl status for mysqld.service:

Arch Linux Plasma 5 | AMD Ryzen 7 1700 | 16GB DDR4 RAM | Nvidia GeForce GTX 980

#10 2013-10-13 04:36:40

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

I decided to finally upgrade on the home server and ran into the same exact problem. I can confirm that removing the above two log files also resolved my issue.

#11 2014-07-30 06:31:37

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

OK, so I had a similar error:

Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Plugin ‘FEEDBACK’ is disabled.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Recovering after a crash using mysql-bin
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Starting crash recovery.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Crash recovery finished.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table ‘mysql.gtid_slave_pos’ doesn’t exist
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Can’t open and lock privilege tables: Table ‘mysql.servers’ doesn’t exist
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Server socket created on IP: ‘0.0.0.0’.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Fatal error: Can’t open and lock privilege tables: Table ‘mysql.user’ doesn’t exist
Jul 29 22:50:22 SMILEplug systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE

I solved it with the following commands:

1. Delete everything in /var/lib/mysql
2. mysql_install_db —user=mysql —ldata=/var/lib/mysql/ —basedir=/usr

#12 2014-07-31 20:07:35

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I had a similar problem and none of the above worked.
Even though I had just installed mariadb and rebooted (shutdown -r now), it seemed that starting over so to speak fixed the problem

sudo systemctl stop mysqld
sudo rm -R /var/lib/mysql
sudo pacman -R mariadb && sudo pacman -S mariadb

Instead of trying to start the service I followed the instructions provided by the mariadb install:

You can start the MariaDB daemon with:
cd ‘/usr’ ; sudo /usr/bin/mysqld_safe —datadir=’/var/lib/mysql’

I then could run the mysql_upgrade as root.

I **haven’t** run the mysqld via systemctl start however.

#13 2016-07-11 13:11:44

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I have same issue
[suzan@suzzu

]$ sudo systemctl start mysqld
[sudo] password for suzan:
Job for mysqld.service failed because a timeout was exceeded.
See «systemctl status mysqld.service» and «journalctl -xe» for details.
[suzan@suzzu

]$ sudo systemctl status mysqld
[sudo] password for suzan:
* mysqld.service — MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor preset: disabled)
Active: activating (start-post) (Result: exit-code) since Mon 2016-07-11 18:55:13 NPT; 49s ago
Process: 28647 ExecStart=/usr/bin/mysqld —pid-file=/run/mysqld/mysqld.pid (code=exited, status=1/FAILURE)
Main PID: 28647 (code=exited, status=1/FAILURE); : 28648 (mysqld-post)
Tasks: 2 (limit: 512)
CGroup: /system.slice/mysqld.service
`-control
|-28648 /bin/sh /usr/bin/.
`-29044 sleep 1

Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Plugin ‘FEEDBACK’ is disabled.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Could not open mysql.plugin table. Some plugins may be not l
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Recovering after a crash using mysql-bin
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Starting crash recovery.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Crash recovery finished.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869392640 [Warning] Failed to load slave replication state from table mysql.gt
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Can’t open and lock privilege tables: Table ‘mysql.servers’
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Server socket created on IP: ‘::’.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Fatal error: Can’t open and lock privilege tables: Table ‘my
Jul 11 18:55:14 suzzu systemd[1]: mysqld.service: Main process exited, code=exited, status=1/FAILURE
lines 1-21/21 (END)

#14 2016-07-11 13:29:03

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

If the solution that worked for lonaowna doesn’t work for you, then you don’t have the same problem. Open a new topic about your issue and link back to this one if you think it is still relevant after three years.

Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Источник

Atomic Spin

Atomic Object’s blog on everything we find fascinating.

MySQL: Failed Registration of InnoDB as a Storage Engine

It happens countless times for many reasons. You attempt to start or restart your “MySQL server”:http://dev.mysql.com/ after a small configuration change and MySQL stubbornly refuses to start. Or, if it does start, some important functionality, such as “InnoDB”:http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html support, is missing.

Most Linux users will be familiar with the following pleasant response:

In the case of a configuration change, MySQL clearly fails to start because of the change, but why? Some changes, such as the size of a log file, seem trivial.

Sometimes the cause can be difficult to track down, especially if you don’t know where to look for clues.

h2. MySQL Logging

MySQL has “many types of logs…”:http://dev.mysql.com/doc/refman/5.0/en/server-logs.html a general query log, a connection log, an error log, a binary log, a slow query log, etc. And then there are the Linux system logs.

In the case of a failed MySQL start due to a configuration error or MySQL problem, details are usually output to the “error log”:http://dev.mysql.com/doc/refman/5.0/en/error-log.html. The default location of the error log is the “data directory”:http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html (usually /var/lib/mysql ). The log is normally named based on the hostname of the server. For example, database.example.com.err .

If this file doesn’t seem to exist in your MySQL data directory, MySQL has probably been configured to log elsewhere. Check your my.cnf file, which is normally at /etc/my.cnf . The my.cnf file can contain a log-error option in the [mysqld] section which specifies a different location of the log. If no such option exists and you can’t find the log, try specifying a location for the log yourself, such as log-error = /var/lib/mysq/mysql_error.log

h2. InnoDB Log Files

A common configuration change which can prevent MySQL from starting involves the InnoDB log file size. The “InnoDB log file”:http://www.pythian.com/news/1242/innodb-logfiles/ is the ‘redo’ or recovery log for the InnoDB storage engine. It contains transactions which have been committed to a MySQL table, but which have not yet been written to disk. Should MySQL crash and lose the contents of its buffer pool, the log file can be used to recover any data changes which were in the buffer pool. These recovered data changes can then be written to disk.

The my.cnf file contains a few options which affect the InnoDB log files. In this instance, the key one is innodb_log_file_size . This option sets the size of the InnoDB log file.

h2. Failed Registration of InnoDB as a Storage Engine

Frequently individuals decide to make changes to the innodb_log_file_size option. Generally, they attempt to increase the value, and restart the MySQL server. Unless the “proper procedure”:http://dev.mysql.com/doc/refman/5.0/en/innodb-data-log-reconfiguration.html is followed, MySQL will fail to start (or start without support for InnoDB). The individual may be confused about why MySQL suddenly decided not to start. A quick check of the MySQL error log will usually reveal the cause.

In the case of changing the innodb_log_file_size , one will often find an error similar to the following:

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M 110509 12:04:27 InnoDB: Completed initialization of buffer pool InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes InnoDB: than specified in the .cnf file 0 157286400 bytes! 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ init function returned error. 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed. 110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb 110509 12:04:27 [ERROR] Aborting 110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

While the cause of MySQL’s failure to start is obvious from the log file, this is often overlooked.

There are two solutions to this particular problem:

* Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.

* Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.

The ./ib_logfile0 and ./ib_logfile1 files are located in the InnoDB data directory (usually /var/lib/mysql ). Both files must be moved or renamed for the above procedure to work. When starting MySQL, new InnoDB log files of the appropriate size will be created.

The original InnoDB log files only need to be kept as long as they may be needed for data recovery. If the MySQL server successfully starts after the above procedure, and all data is intact, the original InnoDB log files can be discarded.

Источник

[ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed – How to fix

by Arya MA | Jun 4, 2020

Webmasters usually face “[ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed” while migrating the website or during configuration tweaks.

An unoptimized MySQL configuration entry is the most common reason for this error.

As part of MySQL Support Services, our experts routinely resolve errors such as this. Today we will go through the top causes we have seen for this error, and how we resolve them.

Causes for ‘innodb’ registration as a storage engine failed error

It is common for webmasters or web admins to tweak the parameters of MySQL configuration file. This is primarily to improve the performance of the server.

However, performing tweaks without considering the server resources can adversely affect the server performance. It may even lead to the MySQL service failure.

For instance,innodb_log_file_size is the size of the commit log files which impact the performance of MySQL. Updating the value to a very high level that the server cannot handle leads to MySQL failure with this error.

MySQL upgrade may also trigger this error. The new version of MySQL may not support some of the parameters in the old version. For instance, innodb_log_checksum_algorithm is an experimental feature in 10.0-10.1, which was deprecated in 10.2 and removed in 10.3. Thus there is a chance for the error to be invoked during the upgrade.

A typical error message looks like

How to fix the plugin ‘innodb’ registration as a storage engine failed error?

The first step to fix the error is to find the exact parameter that triggers the error. A closer look at the MySQL configuration file will provide us the details of the configuration.

For instance, one of the requests we recently handled had this line on top of the error message

Obviously the parameter local-inline=0 in MySQL configuration file is triggering the error. To fix the issue, first, we opened the file using an editor

Then we removed the conflicting entry from the configuration file. Next step is to move the redo log files ib_logfile0 and ib_logfile1 to another directory.

Finally, we can restart the MySQL service.

[Need help to Fix the ‘innodb’ registration as a storage engine failed error? We are available 24×7.]

Conclusion

In short, the error message plugin ‘innodb’ registration as a storage engine failed is caused due to incorrect entries in the MySQL configuration file. Today we discussed how our Support Engineers find the exact conflicting entry from the error logs and fix the error easily.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

It happens countless times for many reasons. You attempt to start or restart your MySQL server after a small configuration change and MySQL stubbornly refuses to start. Or, if it does start, some important functionality, such as InnoDB support, is missing.

Most Linux users will be familiar with the following pleasant response:

Problem Statement

MySQL service is stopped.

Sometimes the cause can be difficult to track down, especially if you don’t know where to look for clues.

MySQL Logging

MySQL has many types of logs… a general query log, a connection log, an error log, a binary log, a slow query log, etc. And then there are the Linux system logs.

In the case of a failed MySQL start due to a configuration error or MySQL problem, details are usually output to the error log. The default location of the error log is the data directory (usually /var/lib/mysql). The log is normally named based on the hostname of the server. For example, database.example.com.err.

If this file doesn’t seem to exist in your MySQL data directory, MySQL has probably been configured to log elsewhere. Check your my.cnf file, which is normally at /etc/my.cnf. The my.cnf file can contain a log-error option in the [mysqld] section which specifies a different location of the log. If no such option exists and you can’t find the log, try specifying a location for the log yourself, such as log-error = /var/lib/mysq/mysql_error.log

InnoDB Log Files

A common configuration change which can prevent MySQL from starting involves the InnoDB log file size. The InnoDB log file is the ‘redo’ or recovery log for the InnoDB storage engine. It contains transactions which have been committed to a MySQL table, but which have not yet been written to disk. Should MySQL crash and lose the contents of its buffer pool, the log file can be used to recover any data changes which were in the buffer pool. These recovered data changes can then be written to disk.

The my.cnf file contains a few options which affect the InnoDB log files. In this instance, the key one is innodb_log_file_size. This option sets the size of the InnoDB log file.

Frequently individuals decide to make changes to the innodb_log_file_size option. Generally, they attempt to increase the value, and restart the MySQL server. Unless the proper procedure is followed, MySQL will fail to start (or start without support for InnoDB). The individual may be confused about why MySQL suddenly decided not to start. A quick check of the MySQL error log will usually reveal the cause.

In the case of changing the innodb_log_file_size, one will often find an error similar to the following:

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M 110509 12:04:27 InnoDB: Completed initialization of buffer pool InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes InnoDB: than specified in the .cnf file 0 157286400 bytes! 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ init function returned error. 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed. 110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb 110509 12:04:27 [ERROR] Aborting   110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

Or Error Message:

150206 4:42:12 [ERROR] Plugin 'InnoDB' init function returned error.
150206 4:42:12 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
150206 4:42:12 [ERROR] /usr/sbin/mysqld: unknown variable 'local-inline=0'
150206 4:42:12 [ERROR] Aborting

How to Fix MySQL Error “Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed”?

There are 3 solutions to this particular problem:

• Edite file my.cnf
• Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.
• Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.

Solution 1 

We fixed this error by modifying /etc/my.cnf file and removing the statement “local-inline=0“.

Solution 2

Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.

Solution 3

One of the common possible causes of this error is my.cnf file has been modified and saved with incorrect structure.

1. Login to server via SSH with root access.
2. Navigate to /var/lib/mysql.
3. If you see log files like, ib_logfile0 and ib_logfile1, rename or move them to some other folder.
4. Stop and start the MySQL service.

Webmasters usually face “[ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed” while migrating the website or during configuration tweaks.

An unoptimized MySQL configuration entry is the most common reason for this error.

As part of MySQL Support Services, our experts routinely resolve errors such as this. Today we will go through the top causes we have seen for this error, and how we resolve them.

Causes for ‘innodb’ registration as a storage engine failed error

It is common for webmasters or web admins to tweak the parameters of MySQL configuration file. This is primarily to improve the performance of the server.

However, performing tweaks without considering the server resources can adversely affect the server performance. It may even lead to the MySQL service failure.

For instance,innodb_log_file_size is the size of the commit log files which impact the performance of MySQL. Updating the value to a very high level that the server cannot handle leads to MySQL failure with this error.

MySQL upgrade may also trigger this error. The new version of MySQL may not support some of the parameters in the old version. For instance, innodb_log_checksum_algorithm is an experimental feature in 10.0-10.1, which was deprecated in 10.2 and removed in 10.3. Thus there is a chance for the error to be invoked during the upgrade.

A typical error message looks like

110831 21:20:00 [ERROR] Plugin ‘InnoDB’ init function returned error.
110831 21:20:00 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110831 21:20:00 [ERROR] Unknown/unsupported storage engine: INNODB
110831 21:20:00 [ERROR] Aborting

110831 21:20:00 [Note] /usr/sbin/mysqld: Shutdown complete

How to fix the plugin ‘innodb’ registration as a storage engine failed error?

The first step to fix the error is to find the exact parameter that triggers the error. A closer look at the MySQL configuration file will provide us the details of the configuration.

For instance, one of the requests we recently handled had this line on top of the error message

150206 4:42:12 [ERROR] /usr/sbin/mysqld: unknown variable 'local-inline=0'

Obviously the parameter local-inline=0 in MySQL configuration file is triggering the error. To fix the issue, first, we opened the file using an editor

#vi /etc/my.cnf

Then we removed the conflicting entry from the configuration file. Next step is to move the redo log files ib_logfile0 and ib_logfile1 to another directory.

#cd /var/lib/mysql

#mv ib_logfile0 ib_logfile1 /tmp/

Finally, we can restart the MySQL service.

#service mysqld restart
[root@tech mysql]# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]

[Need help to Fix the ‘innodb’ registration as a storage engine failed error? We are available 24×7.]

Conclusion

In short, the error message plugin ‘innodb’ registration as a storage engine failed is caused due to incorrect entries in the MySQL configuration file. Today we discussed how our Support Engineers find the exact conflicting entry from the error logs and fix the error easily.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Hi ! I come here because I have a trouble since the last update of Mysqld :
I cannot start the daemon with

sudo systemctl start mysqld

I have these problems when i look in journalctl -xn :

mars 26 00:22:14 server mysqld[11593]: InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
mars 26 00:22:14 server mysqld[11593]: InnoDB: than specified in the .cnf file 0 5242880 bytes!
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Plugin 'InnoDB' init function returned error.
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Unknown/unsupported storage engine: InnoDB
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Aborting
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [Note] /usr/bin/mysqld: Shutdown complete
mars 26 00:22:14 server systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE

When I try with mysqld, I have

130326  0:23:21 [Warning] Can't create test file /var/lib/mysql/server.lower-test
130326  0:23:21 [Warning] Can't create test file /var/lib/mysql/server.lower-test
mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13)
130326  0:23:21 [ERROR] Aborting
130326  0:23:21 [Note] mysqld: Shutdown complete

And when I look in /var/lib/mysql/server.err I have these lines

130207 23:32:56 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130322 00:25:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130322  0:25:27 InnoDB: The InnoDB memory heap is disabled
130322  0:25:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130322  0:25:27 InnoDB: Compressed tables use zlib 1.2.7
130322  0:25:27 InnoDB: Initializing buffer pool, size = 128.0M
130322  0:25:27 InnoDB: Completed initialization of buffer pool
130322  0:25:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Error: tried to read 65536 bytes at offset 0 3173376.
InnoDB: Was only able to read 1024.
InnoDB: Fatal error: cannot read from file. OS error number 17.
130322  0:25:30  InnoDB: Assertion failure in thread 139785666135872 in file os0file.c line 2538
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.
23:25:30 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=262144
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 = 134074 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 0x40000
/usr/bin/mysqld(my_print_stacktrace+0x29)[0x78ae99]
/usr/bin/mysqld(handle_fatal_signal+0x471)[0x67ad71]
/usr/lib/libpthread.so.0(+0xf1e0)[0x7f226299a1e0]
/usr/lib/libc.so.6(gsignal+0x35)[0x7f22615612c5]
/usr/lib/libc.so.6(abort+0x148)[0x7f2261562748]
/usr/bin/mysqld[0x8f2ac0]
/usr/bin/mysqld[0x8af1a0]
/usr/bin/mysqld[0x8e187c]
/usr/bin/mysqld[0x8e75ef]
/usr/bin/mysqld[0x834204]
/usr/bin/mysqld[0x7fe61f]
/usr/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x67ccf1]
/usr/bin/mysqld[0x59ad94]
/usr/bin/mysqld(_Z11plugin_initPiPPci+0xa42)[0x59f342]
/usr/bin/mysqld[0x524328]
/usr/bin/mysqld(_Z11mysqld_mainiPPc+0x447)[0x529187]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f226154da15]
/usr/bin/mysqld[0x51ff89]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
130322 00:25:30 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130326 00:24:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130326  0:24:58 InnoDB: The InnoDB memory heap is disabled
130326  0:24:58 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130326  0:24:58 InnoDB: Compressed tables use zlib 1.2.7
130326  0:24:58 InnoDB: Initializing buffer pool, size = 128.0M
130326  0:24:58 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
130326  0:24:58 [ERROR] Plugin 'InnoDB' init function returned error.
130326  0:24:58 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130326  0:24:58 [ERROR] Unknown/unsupported storage engine: InnoDB
130326  0:24:58 [ERROR] Aborting

130326  0:24:58 [Note] /usr/bin/mysqld: Shutdown complete

130326 00:24:58 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130326 00:25:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/
130326  0:25:33 InnoDB: The InnoDB memory heap is disabled
130326  0:25:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130326  0:25:33 InnoDB: Compressed tables use zlib 1.2.7
130326  0:25:33 InnoDB: Initializing buffer pool, size = 128.0M
130326  0:25:33 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
130326  0:25:33 [ERROR] Plugin 'InnoDB' init function returned error.
130326  0:25:33 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130326  0:25:33 [ERROR] Unknown/unsupported storage engine: InnoDB
130326  0:25:33 [ERROR] Aborting

130326  0:25:33 [Note] /usr/bin/mysqld: Shutdown complete

130326 00:25:33 mysqld_safe mysqld from pid file /var/lib/mysql//server.pid ended

When I try mysqld_safe, here is what I get

130326 00:24:58 mysqld_safe Logging to '/var/lib/mysql/server.err'.
130326 00:24:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130326 00:24:58 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended

Resolution
===== It’s a good thing to make a post :
It allows me to order my ideas and I find the solution here http://serverfault.com/questions/104014 … erent-size

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

Last edited by shox (2013-03-25 23:51:43)