The world's most popular open source database
As a general rule, to upgrade from one release series to another, you should go to the next series rather than skipping a series. To upgrade from a release series previous to MySQL 5.1, upgrade to each successive release series in turn until you have reached MySQL 5.1, and then proceed with the upgrade to MySQL 5.4. For example, if you currently are running MySQL 4.0 and wish to upgrade to a newer series, upgrade to MySQL 4.1 first before upgrading to 5.0, and so forth. For information on upgrading to MySQL 5.1, see the MySQL 5.1 Reference Manual; for earlier releases, see the MySQL 3.23, 4.0, 4.1 Reference Manual.
To upgrade from MySQL 5.1 to 5.4, use the items in the following checklist as a guide:
Before any upgrade, back up your databases, including the
mysql database that contains the grant
tables. See Section 6.1, “Database Backup Methods”.
Read all the notes in Section 126.96.36.199, “Upgrading from MySQL 5.1 to 5.4”. These notes enable you to identify upgrade issues that apply to your current MySQL installation. Some incompatibilities discussed in that section require your attention before upgrading. Others should be dealt with after upgrading.
Read Appendix C, MySQL Change History as well, which provides information about features that are new in MySQL 5.4 or differ from those found in MySQL 5.1.
After you upgrade to a new version of MySQL, run mysql_upgrade (see Section 4.4.7, “mysql_upgrade — Check Tables for MySQL Upgrade”). This program checks your tables, and attempts to repair them if necessary. It also updates 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.3.14, “Upgrading MySQL on Windows”.
If you are using replication, see Section 16.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.
If you have created a user-defined function (UDF) with a
given name and upgrade MySQL to a version that implements a
new built-in function with the same name, the UDF becomes
inaccessible. To correct this, use
FUNCTION to drop the UDF, and then use
CREATE FUNCTION to re-create
the UDF with a different nonconflicting name. The same is
true if the new version of MySQL implements a built-in
function with the same name as an existing stored function.
See Section 8.2.4, “Function Name Parsing and Resolution”, for the rules
describing how the server interprets references to different
kinds of functions.
You can always move the MySQL format files and data files between different versions on systems with 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 5.1.13 and want to upgrade to 5.4.10, rename your current server from mysqld to mysqld-5.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
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
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
my.cnf file that affects server
or client operation.
If your MySQL installation contains a large amount of data that
might take a long time to convert after an in-place upgrade, you
might find it useful to create a “dummy” database
instance for assessing what conversions might be needed and the
work involved to perform them. Make a copy of your MySQL
instance that contains a full copy of the
mysql database, plus all other databases
without data. Run your upgrade procedure on this dummy instance
to see what actions might be needed so that you can better
evaluate the work involved when performing actual data
conversion on your original database instance.
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 PHP
mysql extensions and the