| Bug #67040 | mysql_upgrade mystical error | ||
|---|---|---|---|
| Submitted: | 1 Oct 2012 21:44 | Modified: | 15 May 2013 21:32 |
| Reporter: | Peter Laursen (Basic Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Installing | Severity: | S3 (Non-critical) |
| Version: | 5.5.28 | OS: | Windows (7/64) |
| Assigned to: | CPU Architecture: | Any | |
[1 Oct 2012 22:22]
Peter Laursen
correcting version in synopsis
[1 Oct 2012 23:43]
MySQL Verification Team
Thank you for the bug report. I can't repeat: C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql_upgrade.exe -uroot -p Enter password: Looking for 'mysql.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysql.exe Looking for 'mysqlcheck.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqlcheck.exe Running 'mysqlcheck' with connection arguments: "--port=3306" Running 'mysqlcheck' with connection arguments: "--port=3306" 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.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 Running 'mysql_fix_privilege_tables'... OK However I have a doubt about your command line P3307? C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql_upgrade -uroot -p P3307 Enter password: ******** If you try with -P3307 it works? Thanks in advance.
[2 Oct 2012 7:46]
Peter Laursen
The hyphen makes no difference:
C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql_upgrade -uroot -p -P3307
Enter password: ********
Looking for 'mysql.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysql.ex
e
Looking for 'mysqlcheck.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mys
qlcheck.exe
Running 'mysqlcheck' with connection arguments: "--port=3307" "--socket=/tmp/mys
ql.sock" "--port=3307"
Running 'mysqlcheck' with connection arguments: "--port=3307" "--socket=/tmp/mys
ql.sock" "--port=3307"
C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqlcheck.exebug.order_details
OK
: mydb.t OK
Got error: 1103: Incorrect table name '' when executing 'CHECK TABLE ... FOR UP
GRADE'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.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
peter.csvtest OK
peter.u8 OK
portal.old_keys OK
portal.order_details OK
test. blah OK
FATAL ERROR: Upgrade failed
C:\Program Files\MySQL\MySQL Server 5.5\bin>
now in this
: mydb.t OK
Got error: 1103: Incorrect table name '' when executing 'CHECK TABLE ... FOR UP
GRADE'mysql.columns_priv OK
I notice 2 things:
1) how does the ":" before "mydb.t" arrive?
2) "Incorrect table name '' when .." So it *thinks' it finds a table with no/a empty name. But there is only table `t` in `mydb` and all table in `mysql` are OK. the empty table should be last in mydb or last in mysql, right?
[2 Oct 2012 7:49]
Peter Laursen
Droppping `mydb` database does not change anything. So the error must be in `mysql` database. The root cause probably is related to http://bugs.mysql.com/bug.php?id=67041
[2 Oct 2012 12:02]
Peter Laursen
As told elsewhere that I have removed everything from 5.5 and 5.6 and did a fresh install of 5.5.28 and 5.6.7. So I will not be able to reply to more questions about this. All related information has been removed from my system now. But I wonder if MySQL's /datadir safe to use with Windows 'System Restore'/NTFS 'shadow copies'? It could be tested like this: 1) stop server 2) make a backup of datadir (precaution!) 3) create a System Restore-point 4) delete everything inside datadir 5) recover datadir from last NTFS 'shadow copy' 6) start server and run "mysql_upgrade --force". Does mysql_upgrade complain about a table with an empty name? .. but I don't intend to do it now. It took a couple of hours to recover from errors resulting from a (should have been) quite simple upgrade from 5.5.23 to 5.5.28. Do as you like with this report!
[2 Oct 2012 13:26]
Vladislav Vaintroub
Peter, please allow me to answer this question on shadow copy(I do not believe MySQL support will answer this, this I just jump in). Basically, if for storage engines that are crash-safe, volume snapshots (or shadow copies) work fine. Hence, Innodb is safe, at least in theory. The new start is akin to crash recovery process. Otherwise (think MyISAM), volume snapshots taken at the moment when database is online are unsafe, and in general case there must be a repair process. There is one exception though - volume snapshot taken at the moment between "flush tables with read lock" and "unlock tables" is always safe, however, it still might need innodb recovery, since innodb background threads might be still be writing to the disk, even after "flush".
[2 Oct 2012 13:48]
Peter Laursen
Thanks to @wlad for explaining. It makes sense. Now *something* happened to my `mysql` database (with MyISAM tables) as far as I can understand. The 5.5.28 installer created a Restore Point. But the service was manually shut down, as the installer required it. This should ensure that everything was flushed to disk. But maybe the restore point is created *before* it prompts user to stop the service? But anyway .. Windows may create Restore Points for other reasons than when MySQL is upgraded! After recovering from the restore point/shadow copy mysql_upgrade complains about an (as far as I can see) non-existing table with an empty name. Inspecting the file system did not give me a clue why. I think it is serious if system database/tables can be invalidated by performing a 'System Restore'. Not sure if it can be avoided. Anybody knows what SQL Server does (if any database server handles it, it must be SQL Server)? Actually 'shadow copy technique' could be used as a (nice) backup method on Windows (if it worked) - not unlike to LVM on Linux.
[4 Oct 2012 5:36]
MySQL Verification Team
what is this table? "test. blah " Can you send us a directory listing of your test database ?
[4 Oct 2012 5:49]
MySQL Verification Team
If any table contains "weird" characters in it's name, consider trying: mysql_upgrade --default-character-set=utf8 or mysql_upgrade --default-character-set=binary
[4 Oct 2012 7:38]
Peter Laursen
Sorry but I deleted everything. .. but I did have a table named ` blah` or ` blah ` or similar in the `test` database. This is a valid name for a table (from MySQL 5.1). I should have a backup somehwere from where I can do a "dir". Will check later.
[15 May 2013 21:32]
Yngve Svendsen
Seems we are not able to get any further in investigating this. Closing.
Description: I am upgrading from 5.5.23 to 5.5.28. C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql_upgrade -uroot -p P3307 Enter password: ******** Looking for 'mysql.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysql.ex e Looking for 'mysqlcheck.exe' as: C:\Program Files\MySQL\MySQL Server 5.5\bin\mys qlcheck.exe Running 'mysqlcheck' with connection arguments: "--port=3307" "--socket=/tmp/mys ql.sock" Running 'mysqlcheck' with connection arguments: "--port=3307" "--socket=/tmp/mys ql.sock" C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqlcheck.exebug.order_details OK : mydb.t OK Got error: 1103: Incorrect table name '' when executing 'CHECK TABLE ... FOR UP GRADE'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.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 peter.csvtest OK peter.u8 OK portal.old_keys OK portal.order_details OK test. blah OK FATAL ERROR: Upgrade failed C:\Program Files\MySQL\MySQL Server 5.5\bin> How to repeat: Run mysql_upgrade after upgrade from 5.5.23 to 5.5.28. Suggested fix: I don't have a table nor any file in my /dataddir named with 'empty string'. Due to poor formatting of the consssole output I am not able to see what exactly is complained about. Why 'running' twice BTW?