MySQL AB :: MySQL 5.1 Reference Manual :: 2.11.1 Upgrading from MySQL 5.0 to 5.1

2.11.1. Upgrading from MySQL 5.0 to 5.1

When upgrading a 5.0 installation to 5.0.10 or above note that it is necessary to upgrade your grant tables. Otherwise, creating stored procedures and functions might not work. The procedure for doing this is described in Section 5.5.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.

Note: 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. MySQL recommends that you dump and reload your tables from any previous version to upgrade to 5.1.

In general, you should do the following when upgrading from MySQL 5.0 from 5.1:

Check the items in Section 2.11, “Upgrading MySQL”, to see whether any of them might affect your applications.
Check the items in the change lists found later in this section to see whether any of them might affect your applications. Note particularly any that are marked Incompatible change. These result in incompatibilities with earlier versions of MySQL, and may require your attention before you upgrade.
Some releases of MySQL introduce incompatible changes to tables. (Our aim is to avoid these changes, but occasionally they are necessary to correct problems that would be worse than an incompatibility between releases.) Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features.

To avoid problems due to such changes, after you upgrade to a new version of MySQL, you should run mysql_upgrade to check your tables (and repair them if necessary), and to 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 5.5.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.
Read the MySQL 5.1 change history to see what significant new features you can use in 5.1. See Section C.1, “Changes in release 5.1.x (Development)”.
If you are running MySQL Server on Windows, see Section 2.3.14, “Upgrading MySQL on Windows”.
If you are using replication, see Section 6.3.3, “Upgrading a Replication Setup”, for information on upgrading your replication setup.

The following lists describe changes that may affect applications and that you should watch out for when upgrading to MySQL 5.1.

Configuration Changes:

Before MySQL 5.1.11, to build MySQL from source with SSL support enabled, you would invoke configure with either the --with-openssl or --with-yassl option. In MySQL 5.1.11, those options both have been replaced by the --with-ssl option. By default, --with-ssl causes the bundled yaSSL library to be used. To select OpenSSL instead, give the option as --with-ssl=path, where path is the directory where the OpenSSL header files and libraries are located.

Server Changes:

Incompatible change: MySQL 5.1 implements support for a plugin API that allows the loading and unloading of components at runtime, without restarting the server. Section 26.2, “The MySQL Plugin Interface”. The plugin API requires the mysql.plugin table. When upgrading from an older version of MySQL, you should run the mysql_upgrade command to create this table. See Section 5.5.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.

Plugins are installed in the directory named by the plugin_dir system variable. This variable also controls the location from which the server loads user-defined functions (UDFs), which is a change from earlier versions of MySQL. That is, all UDF library files now must be installed in the plugin directory. When upgrading from an older version of MySQL, you must migrate your UDF files to the plugin directory.
Incompatible change: The table_cache system variable has been renamed to table_open_cache. Any scripts that refer to table_cache should be updated to use the new name.
Incompatible change: As of MySQL 5.1.15, the following conditions apply to enabling the read_only system variable:
- If you attempt to enable read_only while you have any explicit locks (acquired with LOCK TABLES or have a pending transaction, an error will occur.
- If other clients hold explicit table locks or have pending transactions, the attempt to enable read_only blocks until the locks are released and the transactions end. While the attempt to enable read_only is pending, requests by other clients for table locks or to begin transactions also block until read_only has been set.
- read_only can be enabled while you hold a global read lock (acquired with FLUSH TABLES WITH READ LOCK) because that does not involve table locks.
Previously, the attempt to enable read_only would return immediately even if explicit locks or transactions were pending, so some data changes could occur for statements executing in the server at the same time.
Incompatible change: The number of function names affected by IGNORE_SPACE was reduced significantly in MySQL 5.1.13, from about 200 to about 30. (For details about IGNORE_SPACE, see Section 9.2.4, “Function Name Parsing and Resolution”.) This change improves the consistency of parser operation. However, it also introduces the possibility of incompatibility for old SQL code that relies on the following conditions:
- IGNORE_SPACE is disabled.
- The presence or absence of whitespace following a function name is used to distinguish between a built-in function and stored function that have the same name (for example, PI() versus PI ()).
For functions that are no longer affected by IGNORE_SPACE as of MySQL 5.1.13, that strategy no longer works. Either of the following approaches can be used if you have code that is subject to the preceding incompatibility:
- If a stored function has a name that conflicts with a built-in function, refer to the stored function with a schema name qualifier, regardless of whether whitespace is present. For example, write schema_name.PI() or schema_name.PI ().
- Alternatively, rename the stored function to use a non-conflicting name and change invocations of the function to use the new name.
Incompatible change: For utf8 columns, the full-text parser incorrectly considered several non-word punctuation and whitespace characters as word characters, causing some searches to return incorrect results. The fix involves a change to the full-text parser in MySQL 5.1.12, so as of 5.1.12, any tables that have FULLTEXT indexes on utf8 columns must be repaired with REPAIR TABLE:
```
REPAIR TABLE tbl_name QUICK;
```
Incompatible change: The structure of FULLTEXT indexes has been changed in MySQL 5.1.6. After upgrading to MySQL 5.1.6 or greater, call the REPAIR TABLE statement for each table that contains any FULLTEXT indexes.
Incompatible change: Before MySQL 5.1.6, the server writes general query log and slow query log entries to log files. As of MySQL 5.1.6, the server's logging capabilities for these logs are more flexible. Log entries can be written to log files (as before) or to the general_log and slow_log tables in the mysql database. If logging is enabled, either or both destinations can be selected. The --log-output option controls the destination or destinations of log output. See Section 5.11.1, “Selecting General Query and Slow Query Log Output Destinations”.

If logging is enabled, the default destination now is to log to tables, which differs from earlier versions. If you had the server configured for logging to log files formerly, use --log-output=FILE to preserve this behavior after an upgrade to MySQL 5.1.6 or higher.
Incompatible change: For ENUM columns that had enumeration values containing commas, the commas were mapped to 0xff internally. However, this rendered the commas indistinguishable from true 0xff characters in the values. This no longer occurs. However, the fix requires that you dump and reload any tables that have ENUM columns containing true 0xff in their values: Dump the tables using mysqldump with the current server before upgrading from a version of MySQL 5.1 older than 5.1.15 to version 5.1.15 or newer.
As of MySQL 5.1.12, the lc_time_names system variable specifies the locale that controls the language used to display day and month names and abbreviations. This variable affects the output from the DATE_FORMAT(), DAYNAME() and MONTHNAME() functions. See Section 5.10.9, “MySQL Server Locale Support”.
As of MySQL 5.1.6, special characters in database and table identifiers are encoded when creating the corresponding directory names and filenames. This relaxes the restrictions on the characters that can appear in identifiers. See Section 9.2.3, “Mapping of Identifiers to Filenames”. When you run mysql_upgrade, it will cause database and table names to be updated to the new format should they contain special characters.
As of MySQL 5.1.9, mysqld_safe no longer implicitly invokes mysqld-max if it exists. Instead, it invokes mysqld unless a --mysqld or --mysqld-version option is given to specify another server explicitly. If you previously relied on the implicit invocation of mysqld-max, you should use an appropriate option now.

SQL Changes:

Incompatible change: As of MySQL 5.1.8, TYPE = engine_name is still accepted as a synonym for the ENGINE = engine_name table option but generates a warning. You should note that this option is not available in MySQL 5.1.7, and is to be removed altogether in MySQL 5.2, where it will produce a syntax error.

TYPE has been deprecated since MySQL 4.0.
Incompatible change: The namespace for triggers has changed in MySQL 5.0.10. Previously, trigger names had to be unique per table. Now they must be unique within the schema (database). An implication of this change is that DROP TRIGGER syntax now uses a schema name instead of a table name (schema name is optional and, if omitted, the current schema will be used).

When upgrading from a previous version of MySQL 5 to MySQL 5.0.10 or newer, you must drop all triggers and re-create them or DROP TRIGGER will not work after the upgrade. Here is a suggested procedure for doing this:
1. Upgrade to MySQL 5.0.10 or later to be able to access trigger information in the INFORMATION_SCHEMA.TRIGGERS table. (It should work even for pre-5.0.10 triggers.)
2. Dump all trigger definitions using the following SELECT statement:
```
SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,
              ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ',
              t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
              ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
INTO OUTFILE '/tmp/triggers.sql'
FROM INFORMATION_SCHEMA.TRIGGERS AS t;
```
  The statement uses INTO OUTFILE, so you must have the FILE privilege. The file will be created on the server host; use a different filename if you like. To be 100% safe, inspect the trigger definitions in the triggers.sql file, and perhaps make a backup of the file.
3. Stop the server and drop all triggers by removing all .TRG files in your database directories. Change location to your data directory and issue this command:
```
shell> rm */*.TRG
```
4. Start the server and re-create all triggers using the triggers.sql file: For example in my case it was:
```
mysql> delimiter // ;
mysql> source /tmp/triggers.sql //
```
5. Check that all triggers were successfully created using the SHOW TRIGGERS statement.
Incompatible change: MySQL 5.1.6 introduces the TRIGGER privilege. Previously, the SUPER privilege was needed to create or drop triggers. Now those operations require the TRIGGER privilege. This is a security improvement because you no longer need to grant users the SUPER privilege to enable them to create triggers. However, the requirement that the account named in a trigger's DEFINER clause must have the SUPER privilege has changed to a requirement for the TRIGGER privilege. When upgrading from a previous version of MySQL 5.0 or 5.1 to MySQL 5.1.6 or newer, be sure to update your grant tables as described in Section 5.5.7, “mysql_upgrade — Check Tables for MySQL Upgrade”. This process assigns the TRIGGER privilege to all accounts that had the SUPER privilege. If you fail to update the grant tables, triggers may fail when activated. (After updating the grant tables, you can revoke the SUPER privilege from those accounts that no longer otherwise require it.)
For dates with 4-digit year parts less than 200, an implicit conversion to add a century was applied for date arithmetic performed with DATE_ADD(), DATE_SUB(), + INTERVAL, and - INTERVAL. (For example, DATE_ADD('0050-01-01 00:00:00', INTERVAL 0 SECOND) became '2050-01-01 00:00:00'.) As of MySQL 5.1.11, these operations return NULL rather than an incorrect non-NULL value. (Bug#18997)
Some keywords are reserved in MySQL 5.1 that were not reserved in MySQL 5.0. See Section 9.3, “Reserved Words”.
The LOAD DATA FROM MASTER and LOAD TABLE FROM MASTER statements are deprecated. See Section 13.6.2.2, “LOAD DATA FROM MASTER Syntax”, for recommended alternatives.
The INSTALL PLUGIN and UNINSTALL PLUGIN statements that are used for the plugin API are new. So is the WITH PARSER clause for FULLTEXT index creation that associates a parser plugin with a full-text index. Section 26.2, “The MySQL Plugin Interface”.

C API Changes:

Incompatible change: As of MySQL 5.1.7, the mysql_stmt_attr_get() C API function returns a boolean rather than an unsigned int for STMT_ATTR_UPDATE_MAX_LENGTH. (Bug#16144)

2.11.1. Upgrading from MySQL 5.0 to 5.1

User Comments