MySQL Bugs: #64403: MySQL does not warn of deprecated variables on startup

Bug #64403	MySQL does not warn of deprecated variables on startup
Submitted:	21 Feb 2012 22:35	Modified:	22 Feb 2012 7:27
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S4 (Feature request)
Version:	5.5 and earlier	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	windmill

Description:
MySQL does not generally warn you if you use old variable settings rather than the "new ones". Also there is no comment suggesting that perhaps these old variables will be removed at some later stage.

If you change the variable name then probably for 1 major release you should warn that the old variable name will be removed on the next major release. That gives people 2 releases to adjust their configuration. Currently it seems that this is not done and as a consequence there's a mix of old and new settings especially on systems that have been upgraded over time. This makes the MySQL code more complex and makes the configuration more confusing that necessary. 

How to repeat:
Startup mysql with old variable names in /etc/my.cnf and almost all of these generate *no* warning message indicating they are old variables in the mysql log file.

Suggested fix:
* Please ensure that on start the use of any old variable names generates a warning about this being deprecated, and suggesting that after the next version its use will likely not be supported.
* Then ensure that the code clean is made on the newer version.

Examples I'm aware of and have had to write script to "clean up".
* thread_cache -> thread_cache_size
* key_buffer -> key_buffer_size
* table_cache -> table_open_cache / table_definition_cache
* log-slow-queries -> slow_query_log (OFF/ON) and slow_query_log_file (a warning is provided about this)
* thread_cache -> thread_cache_size

Thank you for the problem report. Indeed, 5.5.21 does not produce any warnings for the variables mentioned.

Note: the list of variables I provided is of course not complete.

See also related posts: 
* http://www.mysqlperformanceblog.com/2012/02/18/can-we-improve-mysql-variable-handling/
* http://blog.wl0.org/2011/11/managing-mysqls-configuration/