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 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:
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.
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,
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
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.
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.
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 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.cnffile to its original state, with an
innodb_log_file_sizeequal to the actual size of the existing InnoDB log files.
- Rename or move both the
./ib_logfile1files, and then start the MySQL server.
./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.
Justin is a DevOps practitioner at Atomic Object. He runs servers, troubleshoots the network, deploys apps, fixes bugs, manages backups, monitors monitoring, and does all manner of general problem solving for Atomic Object and our customers. He often works with configuration management tools like Chef and Puppet, and loves working with Linux.
Comments are closed.