|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
[+/-]
As a general rule, we recommend that when upgrading from one release series to another, you should go to the next series rather than skipping a series. If you wish to upgrade from a release series previous to MySQL 4.1, you should upgrade to each successive release series in turn until you have reached MySQL 4.1, and then proceed with the upgrade to MySQL 5.0. For example, if you currently are running MySQL 3.23 and wish to upgrade to a newer series, upgrade to MySQL 4.0 first before upgrading to 4.1, and so forth. For information on upgrading to MySQL 4.1 or earlier releases, see the MySQL 3.23, 4.0, 4.1 Reference Manual.
The following items form a checklist of things that you should do whenever you perform an upgrade from MySQL 4.1 to 5.0:
Before any upgrade, back up your databases, including the
mysqldatabase that contains the grant tables.Read all the notes in Section 2.4.17.2, “Upgrading from MySQL 4.1 to 5.0â€. These notes will enable you to identify upgrade issues that apply to your current MySQL installation. Read Appendix E, MySQL Change History as well, which provides information about features that are new in MySQL 5.0 or differ from those found in MySQL 4.1.
For any incompatibilities that require your attention before upgrading, deal with them as described in Section 2.4.17.2, “Upgrading from MySQL 4.1 to 5.0â€.
After you upgrade to a new version of MySQL, you should run mysql_upgrade (see Section 4.4.9, “mysql_upgrade — Check Tables for MySQL Upgradeâ€). This program will check your tables, and repair them if necessary. It will also update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. (Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features.)
If you are running MySQL Server on Windows, see Section 2.4.8.14, “Upgrading MySQL on Windowsâ€.
If you are using replication, see Section 17.3.3, “Upgrading a Replication Setupâ€, for information on upgrading your replication setup.
If you are upgrading an installation originally produced by installing multiple RPM packages, it is best to upgrade all the packages, not just some. For example, if you previously installed the server and client RPMs, do not upgrade just the server RPM.
MySQL 5.0.27 is the last version in MySQL 5.0 for which MySQL-Max binary distributions are provided, except for RPM distributions. For RPMs, MySQL 5.0.37 is the last release. After these versions, the features previously included in the mysqld-max server are included in mysqld.
If you previously installed a MySQL-Max distribution that includes a server named mysqld-max, and then upgrade later to a non-Max version of MySQL, mysqld_safe still attempts to run the old mysqld-max server. If you perform such an upgrade, you should remove the old mysqld-max server manually to ensure that mysqld_safe runs the new mysqld server.
You can always move the MySQL format files and data files between different versions on the same architecture as long as you stay within versions for the same release series of MySQL.
If you are cautious about using new versions, you can always rename your old mysqld before installing a newer one. For example, if you are using MySQL 4.1.13 and want to upgrade to 5.0.10, rename your current server from mysqld to mysqld-4.1.13. If your new mysqld then does something unexpected, you can simply shut it down and restart with your old mysqld.
If, after an upgrade, you experience problems with recompiled
client programs, such as Commands out of sync
or unexpected core dumps, you probably have used old header or
library files when compiling your programs. In this case, you
should check the date for your mysql.h file
and libmysqlclient.a library to verify that
they are from the new MySQL distribution. If not, recompile your
programs with the new headers and libraries.
If problems occur, such as that the new mysqld
server does not start or that you cannot connect without a
password, verify that you do not have an old
my.cnf file from your previous installation.
You can check this with the --print-defaults
option (for example, mysqld --print-defaults).
If this command displays anything other than the program name, you
have an active my.cnf file that affects
server or client operation.
It is a good idea to rebuild and reinstall the Perl
DBD::mysql module whenever you install a new
release of MySQL. The same applies to other MySQL interfaces as
well, such as the PHP mysql extension and the
Python MySQLdb module.
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |
User Comments
Reality-check:
Upgrading from 5.0.something to 5.1.25... many hours, ultimately a dead-end.
-- Centos 5.1 and trying to let yum manage everything.
-- I obtained the 5.1.25 community RPMs for client and server.
-- Above article fails to discuss whether to uninstall existing version first or not. When I attempted yum upgrade it didn't see existing install (possibly because of name change from "mysql-server" to MYSQL-community-server?). So I did yum uninstall, which also removed dependent Perl, PHP and Python modules.
-- yum install for server failed to complete... later determined to be inability to start server due to inability to create /var/run/mysqlsd. Fixed perms, and was able to run mysql_upgrade, and start server OK (it preserved existing database, users etc.)
-- yum install for client ran OK.
-- client could not connect to server, because one of the installs had renamed my.cnf, and without that, server and client default to different (or no) mysql.sock. This seems a perennial bug. Fixed that, connects OK.
-- Also able to connect from remote client.
-- Now the fatal part: Embarked on reinstating MYSQL-python, dovecot, php-mysql and perl-DBD-MySQL. Yum says all are dependent on "mysql" 5.0.45 . After finding no guidance on this, I let yum proceed... whereupon yum promptly UNinstalled 5.1 community client AND server (with no prompt or warning).
Bottom line: the final sentence of this article "It's a good idea to rebuild and reinstall [Perl, PHP and Python modules]. "Good idea"???? You can't proceed unless you uninstall them, and then where are the replacements that are compatible? I realize that it's not the job of mysql to provide them, but if upgrading MySQL results in no Perl, Python or PHP to interact with it, perhaps something more helpful could be mentioned here.
Add your own comment.