Bug #59974 | 5.5.8 > 5.5.9 upgrade fails | ||
---|---|---|---|
Submitted: | 6 Feb 2011 12:53 | Modified: | 6 Feb 2011 19:21 |
Reporter: | Peter Laursen (Basic Quality Contributor) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Installing | Severity: | S2 (Serious) |
Version: | 5.5.9 | OS: | Windows ((probably any)) |
Assigned to: | CPU Architecture: | Any | |
Tags: | qc |
[6 Feb 2011 12:53]
Peter Laursen
[6 Feb 2011 13:00]
Peter Laursen
BTW: From the console output I can tell that it *does* connect to my 5.5 instance on port 3307 (and not my 5.1 instance running on port 3306)
[6 Feb 2011 13:07]
Peter Laursen
. and I do not use any authentication plugin or have any PROXY -users. This server has a few 'traditional' users only.
[6 Feb 2011 13:11]
Peter Laursen
and no info here: http://dev.mysql.com/doc/refman/5.5/en/news-5-5-9.html that some special upgrade procedure is necessary when upgrading to 5.5.9 (like was the case with upgrade to 5-5-7)
[6 Feb 2011 13:24]
Peter Laursen
.. and finally after starting server with --no-defaults or --skip-grant-tables options exactly same errors occur with the 'fix-privileges' script.
[6 Feb 2011 14:26]
Peter Laursen
OK .. --no-defaults seems not supported. But --skip-grant-tables is.
[6 Feb 2011 15:44]
Peter Laursen
Where is the 'mysql_fix_privilege_tables.sql' file? In 5.0 and 5.1 I find it in /share folder, but not in 5.5. I am not able to find it at all. Has it been compiled into mysql_upgrade as a resource? I thought I would try to run the script from a client, but since I cannot find the file I cannot! My *idea*/*theory*/ was that when specifying a port <> 3306 table checks would run against the instance of the specified port (what it definitely does), but maybe 'mysql_fix_privilege_tables.sql' would always run against an instance on port 3306? Anyway I have no option to check this as I cannot find the file for 5.5.
[6 Feb 2011 18:38]
Vladislav Vaintroub
Peter, Generally, you have to start mysqlcheck in the target version, in your case not from 5.1 install directory but from 5.5 install directory. There is normally no reason to upgrade from 5.5 to 5.5 (like 5.5.8 to 5.5.9). "normally" means that there must be no changes in system tables between 2 versions that differ only in patch number. I believe this policy will now be broken in 5.5, as Joro has started to modify DDL of privilege tables to correct the infamous bug#59974. Which means an upgrade will not automatically get the changes, and I guess user might have to run mysqlcheck himself. And to answer your question on where is the script - it is compiled into mysqlcheck (not as Windows resource, but in conceptually similar yet OS-agnostic way, namely as long string constant).
[6 Feb 2011 18:48]
Peter Laursen
Obviously my stupid mistake that I started the 5.1.54 version of the program and not 5.5. version: C:\Users\Peter>cd \program files\mysql\mysql server 5.5\bin C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql_upgrade --port=3307 -uroot -p Enter password: ******** Looking for 'mysql.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysql.e e Looking for 'mysqlcheck.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\my qlcheck.exe Running 'mysqlcheck' with connection arguments: "--port=3307" "--port=3307" Running 'mysqlcheck' with connection arguments: "--port=3307" "--port=3307" .. -- tables checks -- Running 'mysql_fix_privilege_tables'... OK C:\Program Files\MySQL\MySQL Server 5.5\bin> So only this remains: 1) I think I have already reported before that 'mysqlcheck' output line is repeated twice. But now this " ... arguments: "--port=3307" "--port=3307" " seems new (but cosmetical only) 2) --port/-P option is not listed at http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html. Maybe this passage "supports the following options, which can be specified on the command line or in the [mysql_upgrade] and [client] option file groups. Other options are passed to mysqlcheck. For example, it might be necessary to specify the --password[=password] option. mysql_upgrade also supports the options for processing option files described at Section 4.2.3.3.1, “Command-Line Options that Affect Option-File Handling”." .. is supposed to describe this (but I don not understand it).
[6 Feb 2011 18:50]
Peter Laursen
I know that there is *generally* no need to run mysql_upgrade when upgrading from a.b.x to a.b.y. But *sometimes* there is. Last time was between 5.5.6 and 5.5.7. So I always do!
[6 Feb 2011 18:56]
Vladislav Vaintroub
Have to correct my previous comment. I was refering to Bug#59038 as one that changes the DDL of system tables and thus requires mysql_upgrade.
[6 Feb 2011 18:56]
Peter Laursen
OK .. 5.5 docs also state "fix_priv_tables represents a script generated internally by mysql_upgrade that contains SQL statements to upgrade the tables in the mysql database." .. what explains that I could not find the script. It is 'generated internally' or 'compiled-in as a resource'. Let us close!
[6 Feb 2011 19:03]
Vladislav Vaintroub
5.5.6 and 5.5.7 were beta, so it was not critical. 5.5.8 on the other hand is GA and that mysql_upgrade needs to run here is (from my point of view) bad.
[6 Feb 2011 19:21]
Peter Laursen
@Vladislav .. I do not think is is *required* with 5.5.8 > 5.5.9. But it *does not harm*. Actually the server seemed to work fine before I ran the correct 'fix_privs' script (what is no loger a script! :) ). I have only made it a habit always to do. http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html .. says: "mysql_upgrade should be executed each time you upgrade MySQL". It does not distinguish 'major' and 'minor' versions. Though *most often* 'minor' upgrades do not require mysql_upgrade, there is no guarantee that it *sometimes* will not. I find a few issues a) with the documentation (first of all --port option not documented - (and --host etc.?) and b) the console output (1: mysqlcheck command repeats twice 2: port is listed twice when specified). The issue are cosmetical and b1) I have already reported in another report. I decided to close here as I have (probably) already too many reports open that are cosmetical-and-close-to-nothing. (Danish term is 'flueknepperi' - but my good and polite habits forbid me to translate it into English where it could offend somebody! You always have to be careful with the sentiments of US people as they are not living in the real world:-) )