MySQL Bugs: #68313: mysql_upgrade: unknown variable max_allowed

Bug #68313	mysql_upgrade: unknown variable max_allowed_packet
Submitted:	8 Feb 2013 13:36	Modified:	9 Feb 2013 1:30
Reporter:	Steven Hartland	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	5.6.10	OS:	Any
Assigned to:	Matthew Lord	CPU Architecture:	Any
Tags:	mysql_upgrade

Description:
When upgrading from mysql 5.5 to 5.6.10 mysql_upgrade fails with:-
mysql_upgrade: unknown variable 'max_allowed_packet=16M'

Looking at the code mysql_upgrade loads the config options via "load_default_groups" for client & mysql_upgrade however mysql_upgrade doesn't support all of the client options hence failed.

Workaround is to temporarily remove the unknown vars from my.cnf

How to repeat:
Try to run mysql_upgrade with a max_packet setting in my.cnf for [client] e.g.

== my.cnf ==
[client]
max_allowed_packet = 16M

Suggested fix:
mysql_upgrade loads the config options for client and mysql_upgrade so needs to support all of the client options.

Thank you for taking the time to write to us, but this is not a bug.

All clients read the [client] section, but they of course do not all support the same options.

You can only put things in the [client] section that are supported by all clients. Typically you should just put things like user, port, and socket in there.

http://dev.mysql.com/doc/refman/5.6/en/option-files.html

"The [client] option group is read by all client programs (but not by mysqld). This enables you to specify options that apply to all clients. For example, [client] is the perfect group to use to specify the password that you use to connect to the server. (But make sure that the option file is readable and writable only by yourself, so that other people cannot find out your password.) Be sure not to put an option in the [client] group unless it is recognized by all client programs that you use. Programs that do not understand the option quit after displaying an error message if you try to run them."

This is new and has always worked in the past for all other upgrades so something has changed in 5.6 which causes this regression in behaviour so would appreciate the status is re-evaluated based on that.

I suspect that prior to 5.6 these options where silently ignored, which is clearly not good either.

It might be a good ideas for applications which dynamically load the my.cnf config blocks but don't support them to warn and then ignore said option or to have an option to ignore if its not the default. This would prevent users having to edit their configs just to run app X.

At the very least the messaging should be made clear that its the application that doesn't support the option, as with the current messaging it really gives the impression that these variables have been removed, which is not the case.

Hi Steven,

This is not a bug and it's not new. mysql_upgrade was introduced in MySQL 5.0 and it has always read in the [mysql_upgrade] and [client] groups, and it has always complained about any unknown options, whether they are specified on the command-line, the mysql_upgrade group, or the client group, and in any standard config file or one specified with --defaults[-extra]-file. You are mistaken in thinking that this worked differently before. You can verify this with the mysql_upgrade binary from 5.0, 5.1, and 5.5, just as I have now done, by simply adding max-allowed-packet=10M to the [client] group of a config file (say /tmp/my.cnf) and testing it with /<path to 5.X>/bin/mysql_upgrade --defaults-file=/tmp/my.cnf --help. You'll get the same error with all versions.

This is the way that all client binaries have worked going all the way back to MySQL 3.23. This is basic defaults processing that is done using the exact same method by all mysql client and server binaries.

The [client] group has always worked this way, and has always been documented as working that way. If it ever did NOT work that way, then that's what would have been a bug:
http://dev.mysql.com/doc/refman/4.1/en/option-files.html

Unknown variable: XXXX has been the standard for any binary that processes defaults for 15 years, so I don't think changing it now is warranted. I think that it will cause far more problems than it solves.

I disagree that ignoring unknown options is good, because then you may be specifying values and not realize that they're being ignored.

For example:
mysql_upgrade --usar=root --passwd=foo --no-drop-table

None of these are valid, and that should be made abundantly clear. It's much better to actually know what's being used than to have to deal with an expected error.

There is nothing particular to mysql_upgrade here and this is not a bug. You can see the same thing with any client binary. For example, run mysqlcheck with max_allowed_packet in the client group. Or put an invalid option in the [mysqld] group and try and start the server.

If you would like further help or explanation, please open a support ticket and we'd be happy to discuss it further. We'd also be happy to file a feature request on your behalf, after fleshing it all out with you there.

Best Regards,

Matt