This section is for the special case of upgrading to MySQL 5.5 from the short-lived MySQL 5.4 development series, which is no longer being worked on.
It is good practice to back up your data before installing any new version of software. Although MySQL works very hard to ensure a high level of quality, you should protect your data by making a backup.
To upgrade to 5.5 from any previous version,
MySQL recommends that you dump your tables with
mysqldump before upgrading and reload the
dump file after upgrading. Use the
--all-databases option to
include all databases in the dump. If your databases include
stored programs, use the
--routines and
--events options as well.
In general, you should do the following when upgrading from MySQL 5.4 to 5.5:
Read all the items in these sections to see whether any of them might affect your applications:
Section 2.12.1, “Upgrading MySQL”, has general update information.
The items in the change lists provided later in this section enable you to identify upgrade issues that apply to your current MySQL installation. Some incompatibilities discussed there require your attention before upgrading. Others should be dealt with after upgrading.
The MySQL 5.5 Release Notes describe significant new features you can use in 5.5 or that differ from those found in earlier MySQL releases. Some of these changes may result in incompatibilities.
Note particularly any changes that are marked
Known issue or
Incompatible change. These
incompatibilities with earlier versions of MySQL may require
your attention before you upgrade. Our
aim is to avoid these changes, but occasionally they are
necessary to correct problems that would be worse than an
incompatibility between releases. If any upgrade issue
applicable to your installation involves an incompatibility
that requires special handling, follow the instructions
given in the incompatibility description. Sometimes this
involves dumping and reloading tables, or use of a statement
such as CHECK TABLE or
REPAIR TABLE.
For dump and reload instructions, see
Section 2.12.4, “Rebuilding or Repairing Tables or Indexes”. Any procedure that
involves REPAIR TABLE with
the USE_FRM option
must be done before upgrading. Use of
this statement with a version of MySQL different from the
one used to create the table (that is, using it after
upgrading) may damage the table. See
Section 13.7.2.5, “REPAIR TABLE Syntax”.
Before upgrading to a new version of MySQL, Section 2.12.3, “Checking Whether Tables or Indexes Must Be Rebuilt”, to see whether changes to table formats or to character sets or collations were made between your current version of MySQL and the version to which you are upgrading. If so and these changes result in an incompatibility between MySQL versions, you will need to upgrade the affected tables using the instructions in Section 2.12.4, “Rebuilding or Repairing Tables or Indexes”.
After upgrading to a new version of MySQL, run mysql_upgrade (see Section 4.4.7, “mysql_upgrade — Check and Upgrade MySQL Tables”). 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.)
mysql_upgrade does not upgrade the contents of the help tables. For upgrade instructions, see Section 5.1.10, “Server-Side Help”.
If you run MySQL Server on Windows, see Section 2.3.9, “Upgrading MySQL on Windows”.
If you use replication, see Section 16.4.3, “Upgrading a Replication Setup”, for information on upgrading your replication setup.
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.
The following lists describe changes that may affect applications and that you should watch out for when upgrading from MySQL 5.4 to 5.5.
Incompatible change: In
MySQL 5.5, the server includes a plugin
services interface that complements the plugin API. The
services interface enables server functionality to be
exposed as a “service” that plugins can access
through a function-call interface. The
libmysqlservices library provides access
to the available services and dynamic plugins now must be
linked against this library (use the
-lmysqlservices flag). For an example
showing how to configure for CMake, see
Section 23.2.5, “MySQL Services for Plugins”.
Incompatible change: As of
MySQL 5.5.7, the server requires that a new grant table,
proxies_priv, be present in the
mysql database. If you are upgrading from
a previous MySQL release rather than performing a new
installation, the server will find that this table is
missing and exit during startup with the following message:
Table 'mysql.proxies_priv' doesn't exist
To create the proxies_priv table, start
the server with the
--skip-grant-tables option to
cause it to skip the normal grant table checks, then run
mysql_upgrade. For example:
shell>mysqld --skip-grant-tables &shell>mysql_upgrade
Then stop the server and restart it normally.
You can specify other options on the
mysqld command line if necessary.
Alternatively, if your installation is configured so that
the server normally reads options from an option file, use
the --defaults-file option
to specify the file (enter each command on a single line):
shell>mysqld --defaults-file=/usr/local/mysql/etc/my.cnf--skip-grant-tables &shell>mysql_upgrade
With the --skip-grant-tables
option, the server does no password or privilege checking,
so any client can connect and effectively have all
privileges. For additional security, use the
--skip-networking option as
well to prevent remote clients from connecting.
Incompatible change: As of MySQL 5.5.3, the Unicode implementation has been extended to provide support for supplementary characters that lie outside the Basic Multilingual Plane (BMP). Noteworthy features:
utf16 and utf32
character sets have been added. These correspond to the
UTF-16 and UTF-32 encodings of the Unicode character
set, and they both support supplementary characters.
The utf8mb4 character set has been
added. This is similar to utf8, but
its encoding allows up to four bytes per character to
enable support for supplementary characters.
The ucs2 character set is essentially
unchanged except for the inclusion of some newer BMP
characters.
In most respects, upgrading to MySQL 5.5 should present few problems with regard to Unicode usage, although there are some potential areas of incompatibility. These are the primary areas of concern:
For the variable-length character data types
(VARCHAR and the
TEXT types), the maximum
length in characters is less for
utf8mb4 columns than for
utf8 columns.
For all character data types
(CHAR,
VARCHAR, and the
TEXT types), the maximum
number of characters that can be indexed is less for
utf8mb4 columns than for
utf8 columns.
Consequently, if you want to upgrade tables from
utf8 to utf8mb4 to
take advantage of supplementary-character support, it may be
necessary to change some column or index definitions.
For additional details about the new Unicode character sets and potential incompatibilities, see Section 10.1.10, “Unicode Support”, and Section 10.1.11, “Upgrading from Previous to Current Unicode Support”.
Incompatible change: As of
MySQL 5.5.3, the server includes dtoa, a
library for conversion between strings and numbers by David
M. Gay. In MySQL, this library provides the basis for
improved conversion between string or
DECIMAL values and
approximate-value
(FLOAT/DOUBLE)
numbers.
Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision.
For additional information about the properties of
dtoa conversions, see
Section 12.2, “Type Conversion in Expression Evaluation”.
Incompatible change: In MySQL 5.5, several changes were made regarding the language and character set of error messages:
The --language option for
specifying the directory for the error message file is
now deprecated. The new
lc_messages_dir and
lc_messages system
variables should be used instead, and the server treats
--language as an alias
for lc_messages_dir.
The language system
variable has been removed and replaced with the new
lc_messages_dir and
lc_messages system
variables.
lc_messages_dir has
only a global value and is read only.
lc_messages has global
and session values and can be modified at runtime, so
the error message language can be changed while the
server is running, and individual clients each can have
a different error message language by changing their
session lc_messages
value to a different locale name.
Error messages previously were constructed in a mix of
character sets. This issue is resolved by constructing
error messages internally within the server using UTF-8
and returning them to the client in the character set
specified by the
character_set_results
system variable. The content of error messages therefore
may in some cases differ from the messages returned
previously.
For more information, see Section 10.2, “Setting the Error Message Language”, and Section 10.1.6, “Character Set for Error Messages”.
Before MySQL 5.1.36, plugin options were boolean options
(see Section 4.2.3.2, “Program Option Modifiers”). If you upgrade to
MySQL 5.5 from a version older than 5.1.36 and
previously used options of the form
--
or
plugin_name=0--,
the equivalent options are now
plugin_name=1--
and
plugin_name=OFF--,
respectively. You also have the choice of requiring plugins
to start successfully by using
plugin_name=ON--
or
plugin_name=FORCE--.
plugin_name=FORCE_PLUS_PERMANENT
Incompatible change:
Previously, the parser accepted an INTO
clause in nested SELECT
statements, which is invalid because such statements must
return their results to the outer context. As of MySQL
5.5.3, this syntax is no longer permitted and statements
that use it must be changed.
Some keywords may be reserved in MySQL 5.5 that were not reserved in MySQL 5.4. See Section 9.3, “Reserved Words”.

User Comments
Add your own comment.