MySQL Bugs: #19027: MySQL 5.0 starts even with Fatal InnoDB errors

Bug #19027	MySQL 5.0 starts even with Fatal InnoDB errors
Submitted:	11 Apr 2006 23:50	Modified:	27 Jun 2009 23:36
Reporter:	Peter Zaitsev (Basic Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.0,5.1	OS:	Any (all)
Assigned to:	Kristofer Pettersson	CPU Architecture:	Any
Tags:	qc

Description:
060411 15:35:04  mysqld started
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 268435456 bytes!
060411 15:35:07 [Note] /opt/mysql/libexec/mysqld: ready for connections.
Version: '5.0.19-log'  socket: '/opt/mysql/var/run/mysqld/mysqld.sock'  port: 3306  Source distribution

The cause of this is  - MySQL is started  successfully (it fails in such case in 4.1 and above) which leads to all Innodb tables become inaccessible which may cause strange behavior especially if application does not control errors well. 

How to repeat:
change innodb_log_file_size to some different value.

Suggested fix:
Failing in such case is better.  If  it is desired to have MySQL started even if one of storage engines fails to initialize it should be an option.

Changing the category to MySQL Server, since InnoDB cannot force mysqld not to start (except through generating an assertion failure :)).

handler.cc:

int ha_init()
{
  int error= 0;
  handlerton **types;
  show_table_alias_st *table_alias;
  total_ha= savepoint_alloc_size= 0;

  if (ha_init_errors())
    return 1;

  /*
    We now initialize everything here.
  */
  for (types= sys_table_types; *types; types++)
  {
    if (!(*types)->init || !(*types)->init())
      ha_was_inited_ok(types);
    else
      (*types)->state= SHOW_OPTION_DISABLED;
  }

  DBUG_ASSERT(total_ha < MAX_HA);
  /*
    Check if there is a transaction-capable storage engine besides the
    binary log (which is considered a transaction-capable storage engine in
    counting total_ha)
  */
  opt_using_transactions= total_ha>(ulong)opt_bin_log;
  savepoint_alloc_size+= sizeof(SAVEPOINT);
  return error;
}

Thank you for the bug report.

for us this behavior seems to have caused a big problem; we had the database started without the innodb engine loaded, due to the logfiles being incorrect sizes according to the mysqld.log (InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes).
We didn't notice this in the logfiles, and proceeded to import innodb type tables from another db host using mysqldump over an ssh'd pipe to the mysql utility on the mentioned machine, and all tables seem to have been imported but as MyISAM tables.
This ofcourse is very dangerous, and if our database server just would have refused to start instead of starting but without the innodb engine this would have been prevented

You will see this behaviour also when any innodb_ variables/settings have typos in them. mysqld will start up, but have_innodb=DISABLED.

VERY VERY annoying, and IMHO completely unacceptable behaviour.
MySQL Server will be running, but completely disfunctional.
Please fix this urgently! Thanks

I don't see a sufficient reason to prevent all applications using the server from running just because a storage engine used by some of them can't start. Why kill the message board using MyISAM, the web site using Falcon, the logging application using Archive and the OLAP application using Maria just because a back-office accounting application using InnoDB doesn't run? It's even worse if none of the applications use InnoDB and it's just there because it's present by default.

We have an established pattern already: MyISAM doesn't kill the whole server just because one table is damaged and one storage engine doesn't kill the whole server just because it can't start completely.

InnoDB killing the whole server just because of a checksum failure is already excessive and there isn't sufficient reason to make InnoDB even more unfriendly towards other storage engines and the applications that use them. Unless there's a specific user request in the my.cnf that the storage engine do this.

This would be a nice feature request for a required-storage-engines=<list of engines> feature, so those who do require a certain minimum set of storage engines to start can get that behavior. It would be nice to see this feature added. Then the server could shut down only if the engines that the user cares about don't start properly.

This isn't a bug. It's the server working as it should to minimise the effect of failure in one part of the server. Triage as a bug is inappropriate - it belongs on the feature request list instead, to get that required storage engine option added.

Peter was correct that not starting should be an option.

Reading James' comment I do agree that the whole server should not halt by default. 
Adding it as an option is a nice idea.

The problem arose for us when we didn't realise the InnoDB engine wasn't started, and imported a database dump from the other server. 
It had tables of type InnoDB in it, and if the server does run as James suggests, but encounters an attempt to load InnoDB tables, it should somehow prevent that, by throwing a fatal error or at least not loading those tables but as type MyISAM as has happened in our case.
That seems to be at least a problem, if not a bug. Did we miss any settings that could have prevented that or am I on to something?

@Maarten: sql_mode=NO_ENGINE_SUBSTITUTION

I disagree with James' asessment of the problem.
I'm not debating general errors - of course InnoDB should not stop the whole server on a checksum error. It should capture the error, report it, if need be make its tablespace read-only (like MyISAM does for a corrupted table), and move on.
What the issue is here, is that configuration params that end up being invalid for one reason or another (typo, or directory doesn't exist, or logfile size changes, that kind of stuff), cause InnoDB to be disabled.
In all these cases, the user had a clear intention of using InnoDB, otherwise they wouldn't have put those new settings in the config file! In that scenario, I want the server startup to fail, then the sysadmin will check the errorlog, spot the problem, fix it, and start the server successfully. Problem solved.

Arjen, I expect a DBA to check their work or at least kick themselves if they make a silly mistake.

There are cases where that MyISAM table is crashed behavior or InnoDB not crashing the server would be less than ideal. Say one application and you need all tables to do anything useful.

Then you get things like shared application servers or shared hosting or web service companies where you only want to shut down the minimum possible so you only have one upset customer.

I expect that quite a lot of places with failover setups would want the server to just refuse to start if any of the storage engines that they use is damaged, so they have a really clear indication that they need to fail over. Would be a nice option. How about making a feature request, perhaps also with one for MyISAM that says don't start if any table is damaged?

What's your ideal set of options to handle everything from shared hosting through web services through to packaged applications (installed as part of an application on a Windows end user machine) and whatever other use cases you can think of?

There seems to be majority supporting James D in this issue. So I will try to find a solution not involving shutting down the server.

How about only loading the object names into the MySQL server space, but each time they are accessed we generate errors which can be picked up by cluster-aware software like DB & Network monitor tool/investigating DBA ? This could allow the application layer to take proper action to reroute or cache operations until the SE module is reloaded or the server replaced.

Maarten Stolte: This would address your need for a controlled environment, right?

Example:
% SELECT * FROM inno_table1;
ERROR XXXX (YYYY): 'inno_table1' is offline. The reason might be that the storage engine has failed to start. Check the log file.

% CALL assert_online_tables("inno_table1, inno_table2");
'inno_table1' is offline; server shutting down.

%

The errors seem very clear, and would have prevented my problem if I understand it correctly; we imported a database dump consisting of myisam and innodb tabled. I'd be missing tables in the resulting new database, and thus would investigate, correct? If so, then yes, this is a good solution.

I'll propose this feature request to implemented with these two solutions:
1) Adding a option at boot time for specifying a tolerance level for errors while loading storage engines (and other plugins). Being more specific than that and specify a list of tables/SEs seems redundant. If I as a user remember to maintain  the list I might as well maintain a program to do this check on application level.
2) Adding a way to deal with offline objects. This requires an investigation of the possible states any SE, table and plugin can have. The idea would be that it should later be possible to go from offline to online when the plugin/SE/table is working again. Worklog will be created.

However, target version seems more likely to be set to 6.X instead of 5.0.

Kristofer,

I think you're wrong trying to find one size fits all here.   Working with a lot of environments I can  tell you there are cases when one or another requirement is desired.

Of course in perfect world DBA would check things... and will not make a mistake on the first place. 

Though to be clear it does not have to be DBA to make mistake it could be system administrator (ie permissions can cause the issues) 

My suggestion is to:

1) Make error message reasonable as you propose.

2) Have an option to abort start if there are initialization error.  Leave default what you like.

A note I should add though - if you make things to ignore startup error by default it would be much better if Innodb is made to return error on table IO and make it offline instead of server crash as it happens now.

Current behavior is just silly -  Major error so Innodb can't even start - just continue. Minor error such as checksum table - crash the server.

Ken J: I agree that the core MySQL 'kernel' should be great at managing third party plugins and operate in an intelligent way with the aim to resolve conflicts so that successful execution will be possible.

Peter Z: I agree with your suggestions. :) The server should evolve around principles which doesn't need user aid or interference. As far as possible we should enable the server to resolve all problems automatically in a predictable manner. Specifying server policies and strategies as user settable configuration properties is good but adding more specific (user-) options would mostly be beneficial for third party consultants in my mind. ;)

The bug here is that the behavior isn't very predictable. The feature lacking is to make the server auto-heal from the bad state it ends up in.

I don't think the "one size fits all" argument is applied very well in this context though.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/57998

2675 Kristofer Pettersson	2008-11-06
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      If the InnoDB SE fails to initialize during server start up, there is
      no automatic mechanism for client applications to detect that the meta data
      has changed.
      
      This patch provide a temporary solution to this issue so that if the InnoDB
      SE plugin fails the server won't go online.

I'm providing a temporary solution for 5.1 as there are two independent worklogs in progress already which I believe will affect this bug: WL#3859 and WL#2760

Error: Patch intended to be target for 5.0 as well as 5.1. Once again with a feeling.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/58037

2702 Kristofer Pettersson	2008-11-06
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
            
      If the InnoDB SE fails to initialize during server start up, there is
      no automatic mechanism for client applications to detect that the meta data
      has changed.
            
      This patch provide a solution to this issue so that if the InnoDB,
      CSV or MyISAM SE plugins fail the server won't go online.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/59540

2675 Kristofer Pettersson	2008-11-21
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      If the InnoDB SE fails to initialize during server start up, there is
      no automatic mechanism for client applications to detect that the meta data
      has changed.
                  
      This patch provide a solution to this issue so that if the InnoDB SE plugins
      fail the server won't go online unless the plugin loading mechanism was 
      "--loose-plugin-load" in which case the server will start with best effort.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/72392

2838 Kristofer Pettersson	2009-04-17
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
      
      == This is work in progress ==

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/72421

2838 Kristofer Pettersson	2009-04-17
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
            
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
            
      == This is work in progress ==

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/72506

2838 Kristofer Pettersson	2009-04-20
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
                 
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
               
      == This is work in progress ==

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

http://lists.mysql.com/commits/72586

2838 Kristofer Pettersson 2009-04-21
Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors

It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.

A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.

The behavior is specified as follows:
OFF = Disable the plugin and start the server
ON = Enable the plugin and start the server even if an error occurrs
during plugin initialization.
FORCE = Enable the plugin but don't start the server if an error occurrs
during plugin initialization.

The prefix ENABLE as in "--enable-foobar" will work as "--foobar=ON".
The prefix DISABLE as in "--disable-foobar" will work as "--foobar=OFF".
The prefix LOOSE will continue to work by changing errors into warnings
on a based attempt basis.
@ client/mysql_upgrade.c
* Added member for prefix states to my_option prototype.
@ client/mysqlslap.c
* Added member for prefix states to my_option prototype.
@ extra/my_print_defaults.c
* Added member for prefix states to my_option prototype.
@ extra/mysql_waitpid.c
* Added member for prefix states to my_option prototype.
@ extra/perror.c
* Added member for prefix states to my_option prototype.
@ extra/resolve_stack_dump.c
* Added member for prefix states to my_option prototype.
@ extra/resolveip.c
* Added member for prefix states to my_option prototype.
@ include/my_getopt.h
* Added member for prefix states to my_option prototype.
@ include/sslopt-longopts.h
* Added member for prefix states to my_option prototype.
@ mysql-test/lib/mtr_cases.pm
* Adjusted test case frame work to test the need for innodb against an enumeration
instead of a boolean.
@ mysys/my_getopt.c
* Added documentation
* Changed prototype for function handle_option; removed const restriction.
* Introduced new member in my_option to handle prefix states.
@ server-tools/instance-manager/options.cc
* Added member for prefix states to my_option prototype.
@ sql/mysqld.cc
* Changed boolean --plugin-name to an enumerations { OFF, ON, FORCE }
* Added member for prefix states to my_option prototype.
@ sql/sql_plugin.cc
* Cleaned up argument list for function test_plugin_option by removing
redundant parameter.
* Changed boolean --foobar to enum --foobar with optional arguments { OFF, ON, FORCE }
* Added documentation
* Moved code related to hard coded plugin exceptions to one place.
* Cleaned up argument list for function construct_options.
* Fixed compile warnings on missing paranthesis.
@ sql/sql_plugin.h
* Added member is_mandatory to st_plugin_int structure.
@ storage/archive/archive_reader.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/ft_eval.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/ft_test1.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/mi_test1.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/myisam_ftdump.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/myisamchk.c
* Added member for prefix states to my_option prototype.
@ storage/myisam/myisampack.c
* Added member for prefix states to my_option prototype.
@ storage/ndb/src/kernel/vm/Configuration.cpp
* Added member for prefix states to my_option prototype.
@ tests/mysql_client_test.c
* Added member for prefix states to my_option prototype.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/73015

2877 Kristofer Pettersson	2009-04-29
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
                           
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
            
      A boolean command line option in the form of --foobar is automatically
      created for every existing plugin "foobar". By changing this command line
      option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
      specify the plugin loading policy for each plugin.
            
      The behavior is specified as follows:
       OFF   = Disable the plugin and start the server
       ON    = Enable the plugin and start the server even if an error occurrs
               during plugin initialization.
       FORCE = Enable the plugin but don't start the server if an error occurrs
               during plugin initialization.
     @ mysql-test/lib/mtr_cases.pm
        * Changed --<pluginname> from a boolean to a tristate.
     @ mysys/my_getopt.c
        * Changed --<pluginname> from boolean to tristate. Optional arguments
        must still work for tristates. It is praxis that disable means value 0
        and enable is value 1. Since plugin name is the only tristate with
        optional arguments this principle will still hold.
     @ sql/mysqld.cc
        * Changed --<pluginname> option from a boolean type to a tristate.
     @ sql/sql_plugin.cc
        * Changed --<pluginname> option from a boolean type to a tristate.
     @ sql/sql_plugin.h
        * Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

http://lists.mysql.com/commits/73159

2877 Kristofer Pettersson 2009-04-30
Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors

It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.

A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.

The behavior is specified as follows:
OFF = Disable the plugin and start the server
ON = Enable the plugin and start the server even if an error occurrs
during plugin initialization.
FORCE = Enable the plugin but don't start the server if an error occurrs
during plugin initialization.
@ mysql-test/lib/mtr_cases.pm
* Changed --<pluginname> from a boolean to a tristate. construct_help_options() changes the value of mysqld_variables{'innodb'}
@ mysys/my_getopt.c
* Changed --<pluginname> from boolean to tristate. Optional arguments
must still work for tristates. It is praxis that disable means value 0
and enable is value 1. Since plugin name is the only tristate with
optional arguments this principle will still hold.
@ sql/sql_plugin.cc
* Changed --<pluginname> option from a boolean type to a tristate.
- FORCE will now terminate the server if the plugin fails to
initialize properly.
* Refactored prototypes for test_plugin_options() and construct_options()
to get rid of the 'enable' value pointer.
* Added documentation
@ sql/sql_plugin.h
* Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

http://lists.mysql.com/commits/73275

2877 Kristofer Pettersson 2009-05-04
Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors

It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.

A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.

The behavior is specified as follows:
OFF = Disable the plugin and start the server
ON = Enable the plugin and start the server even if an error occurrs
during plugin initialization.
FORCE = Enable the plugin but don't start the server if an error occurrs
during plugin initialization.
@ mysql-test/lib/mtr_cases.pm
* Changed --<pluginname> from a boolean to a tristate. construct_help_options() changes the value of mysqld_variables{'innodb'}
@ mysys/my_getopt.c
* Changed --<pluginname> from boolean to tristate. Optional arguments
must still work for tristates. It is praxis that disable means value 0
and enable is value 1. Since plugin name is the only tristate with
optional arguments this principle will still hold.
@ sql/sql_plugin.cc
* Changed --<pluginname> option from a boolean type to a tristate.
- FORCE will now terminate the server if the plugin fails to
initialize properly.
* Refactored prototypes for test_plugin_options() and construct_options()
to get rid of the 'enable' value pointer.
* Added documentation
@ sql/sql_plugin.h
* Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

http://lists.mysql.com/commits/73400

2877 Kristofer Pettersson 2009-05-05
Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors

It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.

A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.

The behavior is specified as follows:
OFF = Disable the plugin and start the server
ON = Enable the plugin and start the server even if an error occurrs
during plugin initialization.
FORCE = Enable the plugin but don't start the server if an error occurrs
during plugin initialization.
@ mysql-test/lib/mtr_cases.pm
* Changed --<pluginname> from a boolean to a tristate. construct_help_options() changes the value of mysqld_variables{'innodb'}
@ mysys/my_getopt.c
* Changed --<pluginname> from boolean to tristate. Optional arguments
must still work for tristates. It is praxis that disable means value 0
and enable is value 1. Since plugin name is the only tristate with
optional arguments this principle will still hold.
@ sql/sql_plugin.cc
* Changed --<pluginname> option from a boolean type to a tristate.
- FORCE will now terminate the server if the plugin fails to
initialize properly.
* Refactored prototypes for test_plugin_options() and construct_options()
to get rid of the 'enable' value pointer.
* Cleaned up code related to option name constructing.
* Added documentation
@ sql/sql_plugin.h
* Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/73494

2877 Kristofer Pettersson	2009-05-06
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
      
      A boolean command line option in the form of --foobar is automatically
      created for every existing plugin "foobar". By changing this command line
      option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
      specify the plugin loading policy for each plugin.
      
      The behavior is specified as follows:
       OFF   = Disable the plugin and start the server
       ON    = Enable the plugin and start the server even if an error occurrs
               during plugin initialization.
       FORCE = Enable the plugin but don't start the server if an error occurrs
               during plugin initialization.
     @ mysql-test/lib/mtr_cases.pm
        * Changed --<pluginname> from a boolean to a tristate.
     @ mysys/my_getopt.c
        * Changed --<pluginname> from boolean to tristate. Optional arguments
        must still work for tristates. It is praxis that disable means value 0
        and enable is value 1. Since plugin name is the only tristate with
        optional arguments this principle will still hold.
     @ sql/sql_plugin.cc
        * Changed --<pluginname> option from a boolean type to a tristate.
         - FORCE will now terminate the server if the plugin fails to
           initialize properly.
        * Refactored prototypes for test_plugin_options() and construct_options()
          to get rid of the 'enable' value pointer.
        * Cleaned up code related to option name constructing.
        * Added documentation
     @ sql/sql_plugin.h
        * Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/73809

2877 Kristofer Pettersson	2009-05-12
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
      
      A boolean command line option in the form of --foobar is automatically
      created for every existing plugin "foobar". By changing this command line
      option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
      specify the plugin loading policy for each plugin.
      
      The behavior is specified as follows:
        OFF   = Disable the plugin and start the server
        ON    = Enable the plugin and start the server even if an error occurrs
                during plugin initialization.
        FORCE = Enable the plugin but don't start the server if an error occurrs
                during plugin initialization.
     @ mysql-test/lib/mtr_cases.pm
        * Changed --<pluginname> from a boolean to a tristate.
     @ mysys/my_getopt.c
        * Changed --<pluginname> from boolean to tristate. Optional arguments
          must still work for tristates. It is praxis that disable means value 0
          and enable is value 1. Since plugin name is the only tristate with
          optional arguments this principle will still hold.
     @ sql/sql_plugin.cc
        * Changed --<pluginname> option from a boolean type to a tristate.
        - FORCE will now terminate the server if the plugin fails to
          initialize properly.
        * Refactored prototypes for test_plugin_options() and construct_options()
          to get rid of the 'enable' value pointer.
        * Cleaned up code related to option name constructing.
        * Added documentation
     @ sql/sql_plugin.h
        * Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/74042

2877 Kristofer Pettersson	2009-05-14
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      It is not possible to prevent the server from starting if a mandatory
      built-in plugin fails to start. This can in some cases lead to data
      corruption when the old table name space suddenly is used by a different
      storage engine.
      
      A boolean command line option in the form of --foobar is automatically
      created for every existing plugin "foobar". By changing this command line
      option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
      specify the plugin loading policy for each plugin.
      
      The behavior is specified as follows:
         OFF   = Disable the plugin and start the server
         ON    = Enable the plugin and start the server even if an error occurrs
                 during plugin initialization.
         FORCE = Enable the plugin but don't start the server if an error occurrs
                 during plugin initialization.
     @ mysql-test/lib/mtr_cases.pm
        * Changed --<pluginname> from a boolean to a tristate.
     @ mysys/my_getopt.c
        * Changed --<pluginname> from boolean to tristate. Optional arguments
          must still work for tristates. It is praxis that disable means value 0
          and enable is value 1. Since plugin name is the only tristate with
          optional arguments this principle will still hold.
     @ sql/sql_plugin.cc
        * Changed --<pluginname> option from a boolean type to a tristate.
          - FORCE will now terminate the server if the plugin fails to
            initialize properly.
        * Refactored prototypes for test_plugin_options() and construct_options()
          to get rid of the 'enable' value pointer.
        * Cleaned up code related to option name constructing.
        * Added documentation
     @ sql/sql_plugin.h
        * Introduced new member to st_plugin_int structure.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/74325

2883 Kristofer Pettersson	2009-05-18
      Bug #19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      Fixed bug which read one byte too many in a string.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/74340

2883 Kristofer Pettersson	2009-05-18
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      convert_dash_to_underscore was supplied with a character length containing
      my byte too many which caused valgrind errors of invalid read.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/74369

2885 Kristofer Pettersson	2009-05-18
      Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors
      
      Fixed start up options for test case "rpl_ndb_2other-slave" to match
      the changed behavior for plugin options.

Pushed into 5.1.36 (revid:joro@sun.com-20090528073639-yohsb4q1jzg7ycws) (version source revid:kristofer.pettersson@sun.com-20090518113913-bp9aolwk34cgr3x2) (merge vers: 5.1.36) (pib:6)

matt: Right, that is the idea.

The --skip-xxx and --disable-xxx forms of plugin options work, but the --enable-xxx form does not. For example, if I start the server with --enable-innodb, the server fails with an error:

unknown option '--enable-innodb'

Noted in 5.1.36 changelog.

The server can load plugins under control of startup options. For
example, many storage engines can be built in pluggable form and
loaded when the server starts. In the following descriptions,
plugin_name stands for a plugin name such as innodb.

Previously, plugin options were handled like other boolean options
(see ). That is, any of these options enabled the plugin:

  --plugin_name
  --plugin_name=1
  --enable-plugin_name

And these options disabled the plugin:

  --plugin_name=0
  --disable-plugin_name
  --skip-plugin_name

However, use of a boolean option for plugin loading did not provide
control over what to do if the plugin failed to start properly:
Should the server exit, or start with the plugin disabled? The actual
behavior has been that the server starts with the plugin disabled,
which can be problematic. For example, if InnoDB fails to start,
existing InnoDB tables become inaccessible, and attempts to create
new InnoDB tables result in tables that use the default storage
engine unless the NO_ENGINE_SUBSTITUTION SQL mode has been enabled to
cause an error to occur instead.

Now, there is a change in the options used to control plugin loading,
such that they have a tristate format:

* --plugin_name=OFF

  Do not enable the plugin.

* --plugin_name=ON

  Enable the plugin. If plugin initialization fails, start the server
  anyway, but with the plugin disabled.

* --plugin_name=FORCE

  Enable the plugin. If plugin initialization fails, do not start the
  server. In other words, force the server to run with the plugin or
  not at all.

The values OFF, ON, and FORCE are not case sensitive.

Suppose that CSV and InnoDB have been built as pluggable storage
engines and that you want the server to load them at startup, subject
to these conditions: The server is allowed to run if CSV
initialization fails, but must require that InnoDB initialization
succeed. To achieve these conditions, use these lines in an option
file:

[mysqld]
csv=ON
innodb=FORCE

This change is incompatible with the previous implementation if you
used options of the form --plugin_name=0 or --plugin_name=1, which
should be changed to --plugin_name=OFF or --plugin_name=ON,
respectively.

--enable-plugin_name is still supported and is the same as
--plugin_name=ON. --disable-plugin_name and --skip-plugin_name are
still supported and are the same as --plugin_name=OFF.

Setting report to NDI pending push into 6.0.x.

Patch is pushed into mysql-pe

Pushed into 5.4.4-alpha (revid:alik@sun.com-20090616183122-chjzbaa30qopdra9) (version source revid:kristofer.pettersson@sun.com-20090518114508-2m1zi94p9b1utmu9) (merge vers: 6.0.12-alpha) (pib:11)

Noted in 5.4.4 changelog.

Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:staale.smedseng@sun.com-20090626084621-g6zteyvzehto95j0) (merge vers: 5.1.37) (pib:11)

Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:staale.smedseng@sun.com-20090626084621-g6zteyvzehto95j0) (merge vers: 5.1.37) (pib:11)

Pushed into 5.4.4-alpha (revid:anozdrin@bk-internal.mysql.com-20090710111017-bnh2cau84ug1hvei) (version source revid:kristofer.pettersson@sun.com-20090625140938-71da252h1fs7mmyx) (merge vers: 5.4.4-alpha) (pib:11)

Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.

Ignore previous comment about 5.4.2.

Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)

Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)

Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)

Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)

The 5.4 fix has been pushed into 5.4.2.

Bug #50011 was marked as a duplicate of this one.

I changed the default engine to InnoDB in my.cnf file and now mysql won't start if InnoDB is disabled due to some reason.
# default-storage-engine=InnoDB

@Shantanu That seems perfectly logical to me. Why would you want a disabled storage engine as your default storage engine?