Last modified: 2011-04-04 21:32:40 UTC
When MySQL is configured with sql-mode="NO_ENGINE_SUBSTITUTION" and skip-innodb
in the MySQL configuration file (my.cnf), i.e. InnoDB is disabled and an attempt
to use InnoDB will result in an error message, MediaWiki's desire to use InnoDB
tables will fail during installation:
* Creating tables... using MySQL 3/4 table defs...Query "CREATE
TABLE mw_user ( user_id int(5) unsigned NOT NULL auto_increment,
user_name varchar(255) binary NOT NULL default '', user_real_name
varchar(255) binary NOT NULL default '', user_password tinyblob
NOT NULL default '', user_newpassword tinyblob NOT NULL default
'', user_email tinytext NOT NULL default '', user_options blob
NOT NULL default '', user_touched char(14) binary NOT NULL
default '', user_token char(32) binary NOT NULL default '',
user_email_authenticated CHAR(14) BINARY, user_email_token
CHAR(32) BINARY, user_email_token_expires CHAR(14) BINARY,
PRIMARY KEY user_id (user_id), UNIQUE INDEX user_name
(user_name), INDEX (user_email_token) ) TYPE=InnoDB" failed with
error code "The 'InnoDB' feature is disabled; you need MySQL
built with 'InnoDB' to have it working".
My suggestion would be that MediaWiki should check whether InnoDB is available
(SHOW VARIABLES LIKE 'have_innodb'; should not return DISABLED) and/or the SQL
mode (SHOW VARIABLES LIKE 'sql_mode'; should not contain
NO_ENGINE_SUBSTITUTION), and possibly attempt to set its preference using
dynamic system variables for the session (SET SESSION table_type='InnoDB';), see
http://dev.mysql.com/doc/refman/5.0/en/using-system-variables.html, instead of
always specifying TYPE=InnoDB in its SQL scripts.
MediaWiki relies upon being able to use InnoDB for all the major tables (page,
revision, and text at least need decent transaction support), decent length
indexes and table space.
We're not going to stop specifying a storage engine when we want to use it.
with the forthcoming Falcon storage engine it might make sense to have this be less static; but i don't think
MyISAM will ever work well.
Should check whether the new installer code in 1.10 resolves this issue.
Should be fixed with r52672, we now check to make sure the engines are enabled.