Bug #44638 mysql_upgrade, mysqlcheck output instance unclear
Submitted: 4 May 2009 11:04 Modified: 30 Jun 2009 16:42
Reporter: Susanne Ebrecht Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: General Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Alexey Kopytov CPU Architecture:Any

[4 May 2009 11:04] Susanne Ebrecht
Imagine, you have several MySQL 5.0 instances and want to upgrade one of these to MySQL 5.1.

Of course the my.cnf is not in default path.

You use:

$ mysql_upgrade --defaults-file=FILE

all works fine but mysql_upgrade calls mysqlcheck and it is not clear at the output from mysqlcheck if it really took the right instance.

Looking for 'mysqlcheck' as: ./bin/mysqlcheck
Running 'mysqlcheck'...
Running 'mysqlcheck'..

There is none hint that mysqlcheck really is looking in the instance with default-file=FILE.

That is a little bit confusing.

How to repeat:
Just try to upgrade a 5.0 instance to a 5.1 instance where my.cnf not in default path. Use mysql_upgrade --defaults-file=FILE

Suggested fix:
Add socket or port or something like this here in mysqlcheck output.
[4 May 2009 11:29] Simon Mudd
Not only confusing but has the potential for mistakes and the wrong instances to be changed/checked without this being apparent to the user.
[26 May 2009 15:11] Alexey Kopytov
The proposed fix to mysql_upgrade is to log all connection arguments (host, port, socket, etc.) passed to mysqlcheck to identify the server instance.

We could simply log the entire command line used to invoke mysqlcheck, but this approach is 1) too verbose (many unrelated options, long paths) making it hard to identify the instance 2) potentially insecure (the '--password' option and its value would be logged too, even if it was entered through a tty rather than command line).
[27 May 2009 8:59] Bugs System
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:


2908 Alexey Kopytov	2009-05-27
      Bug #44638: mysql_upgrade, mysqlcheck output instance unclear
      Dump all connection-related arguments when running mysqlcheck
      from mysql_upgrade.
      No test case, since the output depends on the test suite
      configuration and platform.
[1 Jun 2009 6:54] Simon Mudd
Looking at the patch you have provided you register the information of the connection if the explicit host/port/pipe or socket are given as arguments.

In our case we access the server using a defaults file (--defaults-file=/root/.my-some-name.cnf) and in this case no connection will be logged. Ideally the values in the defaults file should be logged, not the name of the defaults file itself.

That is the dev server we are working on which provoked this ticket has a defaults-file:



So I would like to see that the mysql_upgrade/mysqlcheck shows a message like:

Running mysql_upgrade with connection: root@socket/mysql/<instance_name>/data/mysql.sock
Running mysql_upgrade with connection: root@some-host:3306
Running mysql_upgrade with connection: another_user@some-host.domain.com:13306

So please consider adjusting the patch to ALWAYS show the information of the server being connected to whether this is done explicitly on the command line or not.
[1 Jun 2009 7:11] Alexey Kopytov

It may be obvious from the patch itself or the comments, but connection arguments coming from a defaults file are logged too, since the code in my_getopt.c makes it transparent for callers whether the arguments have been read from the command line or from a defaults file.

In your example, the output of the patched mysql_upgrade would be something like:
Looking for 'mysql' as: ...
Looking for 'mysqlcheck' as: ...
Running 'mysqlcheck' with connection arguments: '--socket=/mysql/<instance_name>/data/mysql.sock

i.e. it logs the connection arguments from the defaults file, rather than the --defaults-file command line option itself.
[1 Jun 2009 7:14] Simon Mudd
Hi Alexey,

In that case I apologise. It looked like the patch only caught the specific options on the command line. If I misread this (I didn't look at the full source code) then of course the patch seems fine.

Thanks for the clarification.
[16 Jun 2009 11:03] Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090616102155-3zhezogudt4uxdyn) (version source revid:azundris@mysql.com-20090529164935-xe3dceff53d7pywb) (merge vers: 5.1.36) (pib:6)
[17 Jun 2009 19:28] Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090616183122-chjzbaa30qopdra9) (version source revid:azundris@mysql.com-20090529170733-wxq9j0idmss9rllz) (merge vers: 6.0.12-alpha) (pib:11)
[30 Jun 2009 16:42] Paul DuBois
Noted in 5.1.36, 5.5.4 changelogs.

mysql_upgrade now displays a message indicating the connection
parameters it uses when invoking mysqlcheck.
[12 Aug 2009 21:41] Paul DuBois
Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.
[14 Aug 2009 22:39] Paul DuBois
Ignore previous comment about 5.4.2.
[26 Aug 2009 13:46] Bugs System
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)
[26 Aug 2009 13:46] Bugs System
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)
[26 Aug 2009 13:48] Bugs System
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)
[27 Aug 2009 16:33] Bugs System
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)
[5 Oct 2009 18:16] Paul DuBois
This fix now has been pushed into 5.4.2.