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:
Tags: windmill
Triage: Needs Triage: D5 (Feature request)

[21 Feb 2012 22:35] Simon Mudd
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
[22 Feb 2012 7:17] Valeriy Kravchuk
Thank you for the problem report. Indeed, 5.5.21 does not produce any warnings for the variables mentioned.
[22 Feb 2012 7:27] Simon Mudd
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/