Description:
Customer pointed this out in bug #44640
What I want is to NOT have to upgrade to 5.1 to run mysqlcheck, in order to find there are
tables that I must first dump by downgrading again to 5.0, so I can upgrade back to 5.1 to
reload them. Follow me? Playing start/stop instances with different versions is just
silly.
So what I would really like is that 5.1 CAN read and REPAIR Innodb tables, even those
generated by 5.0 and that this is part of the "standard 5.1 upgrade procedure". (even
mysqldump / load but using 5.1 binaries would be "ok" though probably slower.
I just would like to avoid switching binaries several times just to work out WHAT needs
upgrading and and what doesn't.
That doesn't seem possible now and is frustrating.
****
I'd suggest more than a note in the documentation. Make life easy for the DBA.
Provide tools which tell him what needs to be done (this avoids mistakes), and ensure that
there's a clear step by step procedure for checking what needs to be done and then
performing the upgrade.
So if mysql_upgrade is supposed to "upgrade the server" and mysqlcheck is supposed to
"check what actions need to be done to upgrade the server", then make them work like that
and do the full job.
If not please MENTION explicitly how to check what needs to be done for non-MyISAM tables
and at what moment.
****
A further point that is not clear to me, and might be useful to know.
mysqlcheck is a CLIENT program. Can I successfully run a 5.1 mysqlcheck on a running 5.0
mysqld instance? That is can I check what needs to be done without actually upgrading the
server to 5.1?
If so that would make life MUCH simpler. It's a pain with rpm installations as you don't
support multiple version binaries to be installed at once, but as a temporary solution
binary tarballs can be downloaded and used for this testing (if indeed it works).
So perhaps you can clarify this point. I've assumed it doesn't work but perhaps mysqlcheck
(5.1) could determine it's talking to a 5.0 server and tell you:
* these tables need to be mysqldumped on the 5.0 version and then reloaded after the
upgrade
* these tables need to be upgraded with repair table after upgrading
* etc..
That would be much kinder to the dba, especially if it also detected issues with stored
procedures, triggers and grants which are mentioned in several different places in the
mysql upgrade documentation.
Then if run on a 5.1 server it could say: you forgot to dump these tables and thus must
downgrade to mysqldump them....
How to repeat:
Try to upgrade 200 schemas with millions of data from 5.0 to 5.1.
Suggested fix:
Make mysql_upgrade more comfortable.
© 2024, Oracle Corporation and/or its affiliates