MySQL Bugs: #44638: mysql_upgrade, mysqlcheck output instance unclear

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:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:	Alexey Kopytov	CPU Architecture:	Any

Description:
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.

Not only confusing but has the potential for mistakes and the wrong instances to be changed/checked without this being apparent to the user.

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).

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/75026

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.
      modified:
        client/mysql_upgrade.c

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:

[client]
socket=/mysql/<instance_name>/data/mysql.sock
password=XXXXXXXX

[mysql]
no-auto-rehash

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.

Simon,

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.

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.

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)

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)

Noted in 5.1.36, 5.5.4 changelogs.

mysql_upgrade now displays a message indicating the connection
parameters it uses when invoking mysqlcheck.

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)

This fix now has been pushed into 5.4.2.