mysql_upgrade appears worthless -- broken

Chris_H

Chris_H

Greetings,

Afetr upgrading MySQL server from 5.5.30, to 5.5.32. I followed the instruction at the end, that indicated running mysql_upgrade(1). Which helpfully emitted:
Code: 
mysql_upgrade -u root
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed
Cool! Looks like a successful upgrade. :) Ahem, WTF! Could the output be any less useful? What a WOT! Too bad Oracle had to "improve" MySQL. I think I liked it better when MySQL-AB owned it. Well just checked the database(s). Everything works. I guess it just won't reflect the actual version.

Anybody else run into this problem?

Thank you for all your time, and consideration.

--chris
 
Greetings, and thank you for the reply.

Well, while I haven't read the link yet. I did stop the service(8), prior to performing the upgrade. I read the info presented after the upgrade, and fired off mysql_upgrade(1). Which emitted that nice ERROR. So, I popped open the man page for mysql_upgrade(1), which informed me that I needed to have the service(8) running first:
Code: 
# service mysql-server start
# mysql_upgrade -u root --verbose

Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

#_
So, dunno. I'll have a look at the link you provided.

Thanks again, for taking the time to respond, @cpu82.

--chris
 
Last edited by a moderator:
Greetings @cpu82,

The link you gave me, was the same page as the man page that mysql_upgrade(1) installs. But, there was a comment, by a user at the very bottom of the page, that got me thinking. Comment: mysql_upgrade -u root -p. Nowhere in the info at the end of the install, nor anywhere in the man(1) page, does it suggest you should use root's logon to process the upgrade. I did use -u root, and even --verbose. But all it emitted was ERROR. Not the usual password error received when you omit a password. So. Turns out:
Code: 
# mysql_upgrade -u root -p --verbose
Enter Password:
gets it.

So +1 to you. :)

I think this should be emphasized in the mysql_upgrade(1) man page, or presented/added with the other info, at the end of the upgrade/install.

Thanks again.

--chris
 
Last edited by a moderator:
As far as I know you only need to run it if you change versions (5.0 -> 5.5 for example), not for a minor update.
 
Chris_H said:
I think this should be emphasized in the mysql_upgrade(1) man page, or presented/added with the other info, at the end of the upgrade/install.
Click to expand...
I don't quite agree here because what you're describing is behaviour which even pre-dates the Sun acquisition of MySQL.

Please keep in mind that this behaviour isn't something specific for mysql_upgrade but is common for all MySQL utilities. From the mysql command itself to mysqldump, mysqlcheck and mysqladmin. If you use a MySQL account which has a password assigned to it you need to specify the password parameter.

What does seem out of place though is that the mysql_upgrade manualpage doesn't mention the available --password or -p option.
 
ShelLuser said:
I don't quite agree here because what you're describing is behaviour which even pre-dates the Sun acquisition of MySQL.

Please keep in mind that this behaviour isn't something specific for mysql_upgrade but is common for all MySQL utilities. From the mysql command itself to mysqldump, mysqlcheck and mysqladmin. If you use a MySQL account which has a password assigned to it you need to specify the password parameter.

What does seem out of place though is that the mysql_upgrade manualpage doesn't mention the available --password or -p option.
Click to expand...

Greetings @ShelLuser,

We agree that it is not unusual to require user, and password to perform many maintenance tasks. My gripe is that failure provides no clues -- it is inconsistent with MySQL itself. E.g.:
Code: 
# mysql -u root add
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
as opposed to:
Code: 
# mysql_upgrade -u root --verbose

Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed
Zero indication that the user caused the fail, not the upgrade process.
I hope I am a little clearer this time. :)

Thanks for your response.

--chris
 
Last edited by a moderator:
cpu82 said:
You may also need to stop the MySQL daemon before executing mysql_upgrade(1)() and start it again when finished.

Also see as reference.

EDIT: The mysql_upgrade(1)() man page is based on the MySQL reference manual, until here everything is clear, however it needs some corrections as you can see in the comments of the bottom.

Please, file a PR to the freebsd-doc mailing list to fix the man page.
Click to expand...
Greetings @cpu82, and thank you for your reply.

Will do. Consider it done. :)

--chris
 
Last edited by a moderator:
MySQL is a port, so a PR should go to ports. But really, it sounds like an upstream bug that should be logged in their bug system and fixed there.
 
100% agree. But I did post my experience to freebsd-doc@. At least users that get "bitten", will have a better "clue". :)

--chris
 
Yeah @cpu82! I got a real scolding for that -- THANKS! O.K. I did get a sharp message about it. But it's all good. :) I made the pr(1). So I think it'll be fine for others now. :)

All the best.

--chris
 
Last edited by a moderator:
Hi,

I got an workaround for this similar type of error that I faced.

Code: 
# mysql_upgrade -u root --verbose

Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

This is not the user error. Its just the MySQL client which is in the older version trying to connect with old password formats.
Solution:
Move to the newly installed base_directory/bin and run the mysqlupgrade.
/BASE_DIR/bin#./mysql_upgrade -uroot -p -S<socket>

My analysis:
When I checked mysql_upgrade, it runs the below statements.

Code: 
mysqlcheck --all-databases --check-upgrade --auto-repair
mysql < fix_priv_tables
So I ran mysqlcheck manually with user/password (All privileges- root) and I got the old client error.

I checked the PATH and the mysqlcheck ran and I found another MySQL client installation path. So the clients were mistaken when I ran mysql_upgrade.
 
You must log in or register to reply here.
Back
Top