InnoDB is a storage engine for MySQL. Due to its speedy crash recovery, InnoDB is the preferred engine for high available databases.
But there are times when InnoDB throws error, such as ‘Unknown table engine ‘innodb”. Today, we’ll see when and why this error happens and how to fix it.
What is ‘Unknown table engine ‘innodb” error?
The error message itself clearly says that MySQL service is unable to detect the InnoDB storage engine.
InnoDB engine error manifests itself in different situations:
1. Failure in creating InnoDB tables
Suppose you try to create a new table using the command (“CREATE TABLE t1 (a INT, b CHAR (20), PRIMARY KEY (a)) ENGINE=InnoDB;”).
The table creation fails giving the error – ERROR 1286 (42000) at line 1: Unknown table engine 'innodb'.
Table creation or listing using PhpMyAdmin may also not work. It may not even list the InnoDB storage engine option but instead throw up this error.
2. Using MySQL commands that involve InnoDB
When InnoDB engine is disabled, using certain commands would show this error.
For instance, listing the storage engines using ‘show engines’ command, backing up the databases using mysqldump, etc. are situations where you may end up seeing this error:
mysqldump: Got error: 1286: Unknown table engine 'InnoDB' when using LOCK TABLES
3. MySQL server can fail to start
MySQL may not start with InnoDB engine support. The error shown in the log file would be:
[ERROR] Unknown/unsupported storage engine: InnoDB
4. Error in the websites
All of a sudden, all your database-driven websites can start giving the error along with the database queries:
Notice: Error: Unknown table engine 'InnoDB' Error No: 1286
What causes the error ‘Unknown table engine ‘innodb”
Unknown table engine error happens either because InnoDB storage engine is not enabled in the server or because it got corrupt.
The main reasons that cause the error are:
1. InnoDB not enabled
If the InnoDB engine is disabled in the MySQL database server configuration, it will give error ‘Unknown table engine ‘innodb” whenever you try to create a table with InnoDB support.
It can happen if the MySQL server is not compiled with InnoDB support or if the InnoDB support is disabled via configuration settings.
If the MySQL server was built from source and the built-in InnoDB wasn’t compiled in it, InnoDB engine will not be recognized.
You can check if InnoDB is supported in the server, using the MySQL command:
Check if InnoDB is enabled in server
The value ‘DISABLED’ for ‘have_innodb’ parameter shows that InnoDB is not enabled in that server.
InnoDB engine can also get disabled as a result of a MySQL server upgrade, server migration or manual configuration changes.
If the parameter ‘skip-innodb’ is uncommented in /etc/my.cnf, it will skip loading the InnoDB database engine.
2. Memory shortage
Server not having enough memory to allocate to MySQL, can cause InnoDB to fail. Memory allocation happens based on the parameters such as ‘innodb_buffer_pool_size'.
If the value alloted for this pool size is greater than the available memory limit, InnoDB error occurs.
3. Huge or corrupt log files
In the long run, it so happens that the InnoDB log files grow in size of around GBs or they get corrupt due to some reason. The log files are available at ‘ib_logfile'.
These log files contain the changes to InnoDB data. If they get corrupt, InnoDB will fail to load and ends up giving the error ‘Unknown table engine ‘innodb”.
4. Incorrect permissions for /tmp or socket file
By default, the MySQL server creates its socket file in /tmp or other tmp folder as configured. This folder requires 1777 permissions, for the service to work.
If the /tmp doesn’t have enough permissions to create the socket file, it may end up showing the InnoDB error. InnoDB also fails to run if this folder is full and have no space left.
How to fix the error ‘Unknown table engine ‘innodb”
After identifying the reason for the InnoDB engine error from the error logs, we can apply any of the fixes here, as suited for the situation.
1. Enable InnoDB in the configuration file
If InnoDB support is disabled in the configuration file, here is how to fix it.
Check the ‘/etc/my.cnf’ file. It is the configuration file for MySQL server.
Find the ‘skip-innodb' parameter and comment it by adding # at the beginning of the line:
Enable InnoDB support in my.cnf
Restart the MySQL server and now InnoDB support will be enabled and you would be able to execute commands without the error.
InnoDB engine support enabled in server
2. Recreate the InnoDB log files
InnoDB usually recovers its log files when the MySQL service is started.
So, if the service does not start due to huge or corrupt log files, then rename them and restart MySQL with these steps:
a. Stop MySQL service:
/etc/init.d/mysql stop
b. Rename the log files to some other name
mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bakc. Start MySQL service:
/etc/init.d/mysql startNow the MySQL server would start fine. It will create the log files from the scratch and the InnoDB tables would be accessible without errors.
3. Edit the configuration settings
Edit the following parameters in ‘/etc/my.cnf’ and set optimal values based on the server settings, such as available memory and CPU.
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_buffer_size
innodb_thread_concurrency
These are the parameters that allocate memory and CPU for the InnoDB storage engine. There are no default values for these parameters, but the values can change from server to server.
Always verify the permissions of the ‘tmp’ folder and confirm that enough memory and disk space are available for the MySQL server.
At Bobcares, we also examine the server logs and monitor the MySQL performance and fine-tune the values set for each parameter.
4. Setup MySQL server with InnoDB support
All the above fixes are relevant on servers that already have InnoDB engine compiled with it. MySQL 5.5 versions and above have InnoDB engine enabled by default.
If your MySQL server doesn’t have InnoDB support compiled in, you need to recompile it with InnoDB. If you are running older versions of MySQL, it is best to upgrade your server.
To install the latest version of MySQL server in Ubuntu, use the command:
apt-get install mysql-server-5.6This will install the MySQL server 5.6 with InnoDB support, provided all dependencies are installed.
Points to note..
The file ‘ibdata1’ contains the data of the InnoDB databases and should never be deleted.
So, before doing any changes to MySQL server, we always make a backup of these:
a. MySQL data directory (usually at /var/lib/mysql)
b. MySQL configuration file (default at /etc/my.cnf )
Today we saw the major causes for the error ‘Unknown table engine ‘innodb” and how to fix them. In addition to these, some configuration errors can also lead to errors.
Examining the MySQL error logs, permissions, resources, etc. may be vital to resolve InnoDB related errors. In critical situations, restoring from the backups would also be required.
At Bobcares, we perform crash rescue services with minimal downtime, even for servers with fully corrupt data and no backups.
Read: Database crash rescue – How we re-built an InnoDB MySQL database when ibdata1 file was corrupted
Get a FREE consultation
Do you spend all day answering technical support queries?
Wish you had more time to focus on your business? Let us help you.
We free up your time by taking care of your customers and servers. Our engineers monitor your servers 24/7, and support your customers over help desk, live chat and phone.
Talk to our technical support specialist today to know how we can keep your service top notch!
TALK TO AN EXPERT NOW!
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Bobcares provides Outsourced Hosting Support and Outsourced Server Management for online businesses. Our services include Hosting Support Services, server support, help desk support, live chat support and phone support.
2015-05-13
6 минут read (About 930 words)
Исправление ошибки “Unknown storage engine InnoDB” в MySQL при работе только с MyISAM или после обновления на MySQL 5.6 или MariaDB 10.0
[Warning] Failed to load slave replication state from
table mysql.gtid_slave_pos: 1286: Unknown storage engine 'InnoDB'
Для исправления ошибки, создадим недостающие таблицы в базе mysql.
MariaDB 10.0.хх
CREATE TABLE `gtid_slave_pos` (
`domain_id` int(10) unsigned NOT NULL,
`sub_id` bigint(20) unsigned NOT NULL,
`server_id` int(10) unsigned NOT NULL,
`seq_no` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`domain_id`,`sub_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Replication slave GTID state';
CREATE TABLE `innodb_index_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`index_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
`stat_value` bigint(20) unsigned NOT NULL,
`sample_size` bigint(20) unsigned DEFAULT NULL,
`stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
CREATE TABLE `innodb_table_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`n_rows` bigint(20) unsigned NOT NULL,
`clustered_index_size` bigint(20) unsigned NOT NULL,
`sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
MySQL 5.6.xx
CREATE TABLE `innodb_index_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`index_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
`stat_value` bigint(20) unsigned NOT NULL,
`sample_size` bigint(20) unsigned DEFAULT NULL,
`stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;
CREATE TABLE `innodb_table_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`n_rows` bigint(20) unsigned NOT NULL,
`clustered_index_size` bigint(20) unsigned NOT NULL,
`sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;
CREATE TABLE `slave_master_info` (
`Master_id` int(10) unsigned NOT NULL,
`Number_of_lines` int(10) unsigned NOT NULL,
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Master_log_pos` bigint(20) unsigned NOT NULL,
`Host` text CHARACTER SET utf8 COLLATE utf8_bin,
`User_name` text CHARACTER SET utf8 COLLATE utf8_bin,
`User_password` text CHARACTER SET utf8 COLLATE utf8_bin,
`Port` int(10) unsigned NOT NULL,
`Connect_retry` int(10) unsigned NOT NULL,
`Enabled_ssl` tinyint(1) NOT NULL,
`Ssl_ca` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ssl_capath` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ssl_cert` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ssl_cipher` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ssl_key` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ssl_verify_servert_cert` tinyint(1) NOT NULL,
`Heartbeat` float NOT NULL,
`Bind` text CHARACTER SET utf8 COLLATE utf8_bin,
`Ignored_server_ids` text CHARACTER SET utf8 COLLATE utf8_bin,
`Uuid` text CHARACTER SET utf8 COLLATE utf8_bin,
`Retry_count` bigint(20) unsigned NOT NULL,
`Ssl_crl` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Revocation List (CRL)',
`Ssl_crlpath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path used for Certificate Revocation List (CRL) files',
PRIMARY KEY (`Master_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Master Information';
CREATE TABLE `slave_relay_log_info` (
`Master_id` int(10) unsigned NOT NULL,
`Number_of_lines` int(10) unsigned NOT NULL,
`Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Relay_log_pos` bigint(20) unsigned NOT NULL,
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Master_log_pos` bigint(20) unsigned NOT NULL,
`Sql_delay` int(11) NOT NULL,
PRIMARY KEY (`Master_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Relay Log Information';
CREATE TABLE `slave_worker_info` (
`Id` int(10) unsigned NOT NULL,
`Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Relay_log_pos` bigint(20) unsigned NOT NULL,
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Master_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Checkpoint_relay_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Checkpoint_master_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_seqno` int(10) unsigned NOT NULL,
`Checkpoint_group_size` int(10) unsigned NOT NULL,
`Checkpoint_group_bitmap` blob NOT NULL,
PRIMARY KEY (`Id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Worker Information';
Комментарии
Ok this was actually much easier than expected.
By default SELinux is Enforcing, which prevents unexpected writes on the filesystem. I just needed to tell SELinux that it’s OK for MySQL to write to a non-standard directory. To wit:
[root@ravioli]# semanage fcontext -a -t mysqld_db_t "/databases/mysql(/.*)?"
-bash: semanage: command not found.
Derp. To install semanage, use this:
yum install policycoreutils-python
Now run the command again. This may take a few moments…
[root@ravioli]# semanage fcontext -a -t mysqld_db_t "/databases/mysql(/.*)?"
Check to see that SELinux is configured for this new directory by looking at this config file:
[root@ravioli]# grep -i mysql /etc/selinux/targeted/contexts/files/file_contexts.local
/databases/mysql(/.*)? system_u:object_r:mysqld_db_t:s0
Additional directories can be added, for instance if you have a dedicated tmp directory somewhere.
[root@ravioli]# semanage fcontext -a -t mysqld_db_t "/databases/mysql_tmp(/.*)?"
Check the config again:
[root@ravioli]# grep -i mysql /etc/selinux/targeted/contexts/files/file_contexts.local
/databases/mysql(/.*)? system_u:object_r:mysqld_db_t:s0
/databases/mysql_tmp(/.*)? system_u:object_r:mysqld_db_t:s0
Finally, update the permissions using restorecron
restorecon -R -v /www/databases/mysql/
and in my setup,
restorecon -R -v /www/databases/mysql_tmp/
Now issue:
service mysqld start
Bene.
Starting mysqld: [ OK ]
I recently upgraded from the previous LTS Ubuntu to Precise and now mysql refuses to start. It complains of the following when I attempt to start it:
╰$ sudo service mysql restart
stop: Unknown instance:
start: Job failed to start
And this shows in «/var/log/mysql/error.log»:
120415 23:01:09 [Note] Plugin 'InnoDB' is disabled.
120415 23:01:09 [Note] Plugin 'FEDERATED' is disabled.
120415 23:01:09 [ERROR] Unknown/unsupported storage engine: InnoDB
120415 23:01:09 [ERROR] Aborting
120415 23:01:09 [Note] /usr/sbin/mysqld: Shutdown complete
I’ve checked permissions on all the mysql directories to make sure it had ownership and I also renamed the previou ib_logs so that it could remake them. I’m just getting no where with this issue right now, after looking at google results for 2 hours.
frlan
5731 gold badge8 silver badges27 bronze badges
asked Apr 15, 2012 at 23:24
3
After checking the logs I found the following error:
[ERROR] Unknown/unsupported storage engine: InnoDB
I removed these files:
rm /var/lib/mysql/ib_logfile0
rm /var/lib/mysql/ib_logfile1
at /var/lib/mysql
This resolved my problem after restart.
Apache
2846 silver badges19 bronze badges
answered May 21, 2014 at 5:18
VinayVinay
7495 silver badges2 bronze badges
12
If you really need skip-innodb (use case: low memory footprint), then of course you don’t have to comment it out. However, if InnoDB is the default storage engine, the server will fail to start until you tell it which storage engine to use instead, e.g. default-storage-engine=myisam for MyISAM.
So, try this:
$ sudo -u mysql mysqld --skip-innodb --default-storage-engine=myisam
answered Apr 24, 2012 at 19:03
5
If you’re using MySQL 5.6+ and want to disable InnoDB, don’t forget «—default-tmp-storage» or it won’t work:
To disable InnoDB, use —innodb=OFF or —skip-innodb. In this case,
because the default storage engine is InnoDB, the server will not
start unless you also use —default-storage-engine and
—default-tmp-storage-engine to set the default to some other engine for both permanent and TEMPORARY tables.
http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#option_mysqld_ignore-builtin-innodb
You can add this to your my.cnf:
[mysqld]
innodb=OFF
ignore-builtin-innodb
skip-innodb
default-storage-engine=myisam
default-tmp-storage-engine=myisam
just to make sure it’ll work.
answered Apr 23, 2013 at 21:13
JuanJuan
1191 silver badge2 bronze badges
1
Check your mysql error log.
tail -100 /var/log/mysql/error.log
If your log says (like mine did):
InnoDB: Initializing buffer pool, size = 128.0M InnoDB: mmap(137363456 bytes) failed; errno 12 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
You don’t have enough memory to use the default buffer size of 128M
Edit the config file /etc/mysql/my.cnf adding a line to specify a smaller innodb_buffer_pool_size.
# make the buffer pool smaller than 128M since we only have 1 GB of total RAM
innodb_buffer_pool_size = 16M
Save the config file, and start mysql
sudo service mysql start
answered May 18, 2016 at 16:27
user2219975user2219975
2052 silver badges4 bronze badges
1
I got this error when I deleted the location I use for tmpdir. If you’ve recently changed your tmpdir, you might want to check that it’s a valid, writable location.
answered Aug 14, 2016 at 18:02
JeffJeff
1197 bronze badges
I got this error on a modern MariaDB 10.5 system, because I forgot to units on the innodb control lines;
innodb_buffer_pool_size = 4096
innodb_log_file_size = 1024
instead of
innodb_buffer_pool_size = 4096MB
innodb_log_file_size = 1024MB
So, if you get this one, check there
answered Oct 7, 2022 at 16:33
KirrusKirrus
4822 silver badges11 bronze badges
Check that you have enough free space on the disk.
Run this command to view available free space
df -h
I had this same error message but, once I provisioned more space mysql service was able to start normally
answered Mar 9 at 19:29
Try 2 more things. 1. Lower the innodb buffer pool size. 2. Edit mysql initial script and add —innodb option.
I wonder also if your package is buggy. Could you try a different minor version?
Also, I assume your mysql server got upgraded as well? Maybe that version is broken? Precise is not final yet.
answered Apr 16, 2012 at 3:17
johnshen64johnshen64
5,84523 silver badges17 bronze badges
6
I am trying to use roundcube and it recently just broke. I don’t know if this is due to a MySQL update that happened recently or not but in phpMyAdmin I get the following error if I try and view a table:
1286 - Unknown storage engine 'InnoDB'
and
mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| MyISAM | DEFAULT | MyISAM storage engine | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.00 sec)
and
[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log
[mysqldump]
quick
max_allowed_packet = 512M
[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M
Ideas as to how to fix? It used to work just fine.
asked Mar 13, 2013 at 20:02
1
OBSERVATIONS
- I see there is nothing Innodb-related in the
my.cnf. - Look for Innodb-related error messages expressing why mysqld failed to start in the error log.
My first guess would be look at the ib_logfile0 and ib_logfile1 in /var/lib/mysql.
If they have been set to size different from the default, that probably will prevent mysqld’s startup. The default for innodb_log_file_size is 5M.
SUGGESTION #1
If RoundCube’s installation overwrote the my.cnf, see if you have a physical backup of the previous my.cnf. Put that back in place and run
service mysql start
SUGGESTION #2
Take the filesize of ib_logfile0 and divide by 1048576. Let’s say it is 12M.
Put that in my.cnf
[mysqld]
innodb_log_file_size = 12M
then run
service mysql start
Give it a Try !!!
answered Mar 13, 2013 at 20:32
RolandoMySQLDBARolandoMySQLDBA
179k32 gold badges310 silver badges511 bronze badges
Just delete ib_logfileX files and restart mysql service.
You changed the innodb-log-file-size var to size more bigger than already set it in your mysql daemon.
ypercubeᵀᴹ
96.2k13 gold badges209 silver badges302 bronze badges
answered Aug 2, 2015 at 23:29
1
Petre already wrote it, but perhaps to clarify:
It seems that the InnoDB Engine is not loaded when MySQL cannot write to the temp directory (usually /tmp). This might be caused by either a full temp partition, or incorrect permissions on the temp directory.
As Petre has mentioned chmod 1777 /tmp should resolve this issue. Don’t forget to restart MySQL afterwards.
Marco
3,6804 gold badges22 silver badges30 bronze badges
answered Dec 1, 2016 at 9:00
When you have disable innodb, dont’ forget to remove all innodb-related tables from Dbs. For example «mysql» database has 5 of them:
root@ustimen.co$ mysql mysql -e 'show table status' | grep Unknown | awk '{print $1}'
innodb_index_stats
innodb_table_stats
slave_master_info
slave_relay_log_info
slave_worker_info
answered Jul 27, 2015 at 20:01
gaRexgaRex
1832 silver badges7 bronze badges
I use roundcube, apache2, mysql, dovecot, postfix.
After a harddisk crash and reinstall of the same system on a new HDD I cannot connect to the mail server by web application (roundcube). The message was «Unknown storage engine ‘InnoDB'».
After about 2 weeks of searching the configuration fault without results and by a miracle, today, I saw that some of the linux components cannot write in /tmp.
That’s all that I did … put chmod 1777 /tmp …
Now it’s running ok!
Good luck!
answered Nov 26, 2015 at 12:30
PetrePetre
11 bronze badge