Plugin innodb init function returned error xampp

Mariadb plugin ‘InnoDB’ init function returned error. #93

Comments

When I run command docker-compose up mariadb , I got error likes below

How to build mariadb correctly? Thank advaned!

The text was updated successfully, but these errors were encountered:

I can confirm I’m having the same issue:

I can confirm it too

Same here. Dead in the water.

I thought maybe their default build scripts disable innodb by default. If you ./configure —with-plugin-innodb_plugin instead of using cmake, then make/make install, it will build and install, but attempting to start the server gives the exact same error. I’m going to continue to play with this to see if I can get it to work — is this an actual bug in mariadb?

The only way I found round this was to backup my /var/lib/mysql and /var/lib/mariadb directories by renaming them, then creating them as empty directories. I’m aware this isn’t an option for many, if you’re still in development and working on seed data this should work for you.

There has been some talk about just removing log files from these directories and thus preserving data though I haven’t tried this.

Log files reportedly removed that fixed this issue:

I tried that, and it starts and gets past that point, but then it gives about 1800 lines like this:

InnoDB: wrong number of columns in SYS_INDEXES record

And eventually:
2016-06-21 7:59:51 140678803330944 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2016-06-21 7:59:51 140678803330944 [Warning] InnoDB: Cannot open table mysql/servers from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2016-06-21 7:59:51 140678803330944 [ERROR] Can’t open and lock privilege tables: Table ‘mysql.servers’ doesn’t exist in engine
2016-06-21 7:59:51 140678803330944 [Note] Server socket created on IP: ‘::’.
2016-06-21 7:59:51 140678803330944 [ERROR] Fatal error: mysql.user table is damaged or in unsupported 3.20 format.

What is funny is that if I delete all of the files from my data directory, so there is nothing there at all, I get the exact same error messages. It is as if it does not recognize my mysql database at all.

Maybe my mysql table version is too new for mariadb to recognize. It’s from a production system running mysql 5.7.11, and it is rock solid. If I drop in Mariadb (you know, it’s supposed to be a drop in replacement for mysql, right?) this happens, and I can’t even get the server to start.

I’m going to keep trying, but so far, deleting the log files does not work, and using an empty data directory does not work either.

As an update, if I run mysql_install_db against an empty data directory, it will create the mysql and performance_schema and test databases, and then the server will start.

At this point I conclude:

1. The version of mariadb I’m using, 10.1.14 is not compatible with the tables from mysql 5.7.11

1. Mariadb is not quite the «drop in replacement for mysql» as they would like us to believe.

1. There is a step that I’m missing necessary to make this work with existing mysql tables.

At any rate, until I figure out how to get mariadb to work with an existing mysql database, I have no choice but to stay with mysql.

PS: This is for a production database, and no I’m not going to export all of my production data, create a new mariadb databse, and import all of my data into it. My tables are huge and this simply is not going to happen. Mariadb will either work with the existing mysql data, or I stay with mysql. Until I figure out what I’m missing or doing wrong, I have no choice but to stay with mysql.

I too just experienced the problem that OooK had. After a system reboot, mariadb failed to start, and I got the error message like this:
Fatal error: mysql.user table is damaged or in unsupported 3.20 format.
In my case, the problem was caused by a mysqldump —all-databases from mysql 5.7 and then imported into mariadb 10.1. As stated, there is some difference in mysql.user which caused the problems. Hope this helps someone directed here by google.

I’ll close this old issue now, if the error still exist we’ll open it back.

This error still exists:

mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] mysqld (mysqld 10.1.18-MariaDB-1

jessie) starting as process 1 .
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Using mutexes to ref count buffer pool pages
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: The InnoDB memory heap is disabled
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Compressed tables use zlib 1.2.8
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Using Linux native AIO
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Using SSE crc32 instructions
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Initializing buffer pool, size = 256.0M
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Completed initialization of buffer pool
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] InnoDB: Highest supported file format is Barracuda.
mariadb_1 | InnoDB: No valid checkpoint found.
mariadb_1 | InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
mariadb_1 | InnoDB: please refer to http://dev.mysql.com/doc/refman/5.6/en/upgrading-downgrading.html
mariadb_1 | InnoDB: If this error appears when you are creating an InnoDB database,
mariadb_1 | InnoDB: the problem may be that during an earlier attempt you managed
mariadb_1 | InnoDB: to create the InnoDB data files, but log file creation failed.
mariadb_1 | InnoDB: If that is the case, please refer to
mariadb_1 | InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [ERROR] Plugin ‘InnoDB’ init function returned error.
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [Note] Plugin ‘FEEDBACK’ is disabled.
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [ERROR] Unknown/unsupported storage engine: InnoDB
mariadb_1 | 2016-10-10 17:07:16 140096807745472 [ERROR] Aborting

Tried to rebuild by using
docker-compose up —build —force-recreate -d nginx mariadb

Источник

Issue with InnoDB engine while enabling and [ skip-innodb ] — [ERROR] Plugin ‘InnoDB’ init function returned error

In production server as of now we are running with MyIsam tables only, hence we have disabled the innodb engine with skip-innodb option. But now onwards we need to enable the innodb engine as well for creating few innodb tables. So we have commented the [ #skip-innodb ] option in my.cnf and restarted. Please go through the below cases and request to provide any solution or tips for the same ?

Case 1: Disabled the innodb with skip-innodb option and «mysql>show engines» givens as below.

Case 2: As I want to enable the innodb, I commanded the #skip-innodb option and restarted. But now the show engines even not showing the InnoDB engine in the list. ?

Mysql Version : 5.1.57-community-log OS : CentOS release 5.7 (Final)

1 Answer 1

Your log files could be corrupted.Try this :

1. Stop mysql.
2. Since you had no previous data in the innodb tables, remove (or move elsewhere) the log files, they should be named like /var/lib/mysql/ib_logfile0 and /var/lib/mysql/ib_logfile1 on default install.
3. Start mysql again

To show mysql innodb engine status type this

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

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.

Источник