As a general rule, to upgrade from one release series to another, you should go to the next series rather than skipping a series. For example, if you currently are running MySQL 3.23 and wish to upgrade to a newer series, upgrade to MySQL 4.0 rather than to 4.1 or 5.0.
Whenever you perform an upgrade, 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
Read all the notes the upgrading section for the release series to which you are upgrading. Read the change notes as well. These provide information about new features you can use.
Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features. After you update to a new version of MySQL, you should update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. See Section 4.4.5, “mysql_fix_privilege_tables — Upgrade MySQL System Tables”.
If you run MySQL Server on Windows, see Section 2.3.14, “Upgrading MySQL on Windows”.
If you use replication, see Section 14.6, “Upgrading a Replication Setup”, for information on upgrading your replication setup.
If you upgrade 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 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.
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.3, “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 the same architecture as long as you stay
within versions for the same release series of MySQL. Before MySQL
4.1, if you change the character set when running MySQL, you must
run myisamchk -r -q
MyISAM tables. Otherwise, your indexes
may not be ordered correctly, because changing the character set
may also change the sort order. As of MySQL 4.1, to convert tables
created before 4.1 to the format that includes character set and
collation information, use the instructions in
Section 220.127.116.11, “Converting 4.0 Character Columns to 4.1 Format”.
Normally, you can upgrade MySQL to a newer MySQL version without having to do any changes to your tables. Please confirm whether the upgrade notes to the particular version you are upgrading to tell you anything about this. If there would be any incompatibilities you can use mysqldump to dump your tables before upgrading. After upgrading, reload the dump file using mysql or mysqlimport to re-create your tables.
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 a version of MySQL 4.0 and want to upgrade to 4.1, rename your current server from mysqld to mysqld-4.0. 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 compiled 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. Recompilation might
also be necessary for programs compiled against the shared client
library if the library major version number has changed (for
If problems occur, such as that the new mysqld
server does not want to start or that you cannot connect without a
password, verify that you do not have some 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
my.cnf file that affects server or
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
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
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 and extensions or the