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:
None 
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
Description:
I experienced failure of mysql_upgrade. Yable checks are OK, but 'mysql_fix_privilege_tables' script fails

How to repeat:
C:\Program Files\MySQL\MySQL Server 5.1\bin>mysql_upgrade --port=3307 -uroot -p
Enter password: ********
Looking for 'mysql.exe' as: C:\Program Files\MySQL\MySQL Server 5.1\bin\mysql.ex
e
Looking for 'mysqlcheck.exe' as: C:\Program Files\MySQL\MySQL Server 5.1\bin\mys
qlcheck.exe
Running 'mysqlcheck' with connection arguments: "--port=3306" "--port=3307"
Running 'mysqlcheck' with connection arguments: "--port=3306" "--port=3307"
bugtest.language                                   OK
bugtest.textmaster                                 OK
bugtest.texttranslation                            OK
fktest.child                                       OK
fktest.parent                                      OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.ndb_binlog_index                             OK
mysql.nonsense                                     OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.servers                                      OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
performance_schema.cond_instances                  OK
performance_schema.events_waits_current            OK
performance_schema.events_waits_history            OK
performance_schema.events_waits_history_long       OK
performance_schema.events_waits_summary_by_instance OK
performance_schema.events_waits_summary_by_thread_by_event_name OK
performance_schema.events_waits_summary_global_by_event_name OK
performance_schema.file_instances                  OK
performance_schema.file_summary_by_event_name      OK
performance_schema.file_summary_by_instance        OK
performance_schema.mutex_instances                 OK
performance_schema.performance_timers              OK
performance_schema.rwlock_instances                OK
performance_schema.setup_consumers                 OK
performance_schema.setup_instruments               OK
performance_schema.setup_timers                    OK
performance_schema.threads                         OK
test.a                                             OK
test.auto_table                                    OK
test.b                                             OK
test.blah                                          OK
test.dttest                                        OK
test.g1                                            OK
test.indcmt                                        OK
test.indexcmt                                      OK
test.parent                                        OK
test.sessions                                      OK
test.t1                                            OK
test.tstest                                        OK
test.tttt                                          OK
test.tttttt                                        OK
test.utf8test                                      OK
test-database7.test                                OK
testing.table2                                     OK
testing.table1                                     OK
Running 'mysql_fix_privilege_tables'...
ERROR 1064 (42000) at line 31: You have an error in your SQL syntax; check the m
anual that corresponds to your MySQL server version for the right syntax to use
near '(14), Table_priv set('Select','Insert','Update','Delete','Create','Drop','
Grant'' at line 1
ERROR 1064 (42000) at line 33: You have an error in your SQL syntax; check the m
anual that corresponds to your MySQL server version for the right syntax to use
near '(14), Column_priv set('Select','Insert','Update','References') COLLATE utf
8_gene' at line 1
ERROR 1064 (42000) at line 65: You have an error in your SQL syntax; check the m
anual that corresponds to your MySQL server version for the right syntax to use
near '(14), PRIMARY KEY (Host,Db,User,Routine_name,Routine_type), KEY Grantor (G
rantor' at line 1
ERROR 1064 (42000) at line 452: You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use
 near '(14) AFTER Proc_priv' at line 2
FATAL ERROR: Upgrade failed

Suggested fix:
Not sure. I realize that 5.5.9 may not be officially released. But .msi installer is here: ftp://mirrors.dotsrc.org/mysql/Downloads/

Also this response
Running 'mysqlcheck' with connection arguments: "--port=3306" "--port=3307"
-- mystifies me

and using -P3307 makes no difference as compared to --port=3307

This page: http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html
.. does not list a --port or -P option.  But how am I supposed to upgrade an instance running on port 3307?

(setting a S2 with the risk that I am doing a stupid mistake!)
[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:-) )