This section describes how to downgrade to an older MySQL version.
In the following discussion, MySQL commands that must be run
using a MySQL account with administrative privileges include
-u on the command line
to specify the MySQL rootroot user. Commands that
require a password for root also include a
-p option. Because -p is
followed by no option value, such commands prompt for the
password. Type the password when prompted and press Enter.
SQL statements can be executed using the
mysql command-line client (connect as
root to ensure that you have the necessary
privileges).
Supported downgrade methods include:
In-Place Downgrade: Involves shutting down the new MySQL version, replacing the new MySQL binaries or packages with the old ones, and restarting the old MySQL version on the new data files. In-place downgrades are supported for downgrades between GA versions within the same release series. For example, in-place downgrades are supported for downgrades from 5.5.46 to 5.5.45.
Logical Downgrade: Involves using mysqldump to dump all tables from the new MySQL version, and then loading the dump file into the old MySQL version. Logical downgrades are supported for downgrades between GA versions within the same release series and for downgrades between release levels. For example, logical downgrades are supported for downgrades from 5.5.46 to 5.5.45 and for downgrades from 5.5 to 5.1.
Unless otherwise documented, the following downgrade paths are supported:
Downgrading from a release series version to an older release series version is supported using all downgrade methods. For example, downgrading from 5.546 to 5.5.45 is supported. Skipping release series versions is also supported. For example, downgrading from 5.5.46 to 5.5.44 is supported.
Downgrading one release level is supported using the logical downgrade method. For example, downgrading from 5.5 to 5.1 is supported.
Downgrading more than one release level is supported using the logical downgrade method, but only if you downgrade one release level at a time. For example, you can downgrade from 5.5 to 5.1, and then to 5.0.
The following conditions apply to all downgrade paths:
Downgrades between General Availability (GA) status releases are supported.
Downgrades between milestone releases (or from a GA release to a milestone release) are not supported. For example, downgrading from MySQL 5.5.8 to MySQL 5.5.7 is not supported, as 5.5.7 is not a GA status release.
Before downgrading, the following steps are recommended:
Review the Release Notes for the MySQL version you are downgrading from to ensure that there are no features or fixes that you really need.
Review Section 2.11.2.1, “Changes Affecting Downgrades from MySQL 5.5”. This section describes changes that may require action before or after downgrading.
The downgrade procedures described in the following sections assume you are downgrading with data files created or modified by the newer MySQL version. However, if you did not modify your data after upgrading, downgrading using backups taken before upgrading to the new MySQL version is recommended. Many of the changes described in Section 2.11.2.1, “Changes Affecting Downgrades from MySQL 5.5” that require action before or after downgrading are not applicable when downgrading using backups taken before upgrading to the new MySQL version.
Always back up your current databases and log files before
downgrading. The backup should include the
mysql database, which contains the MySQL
system tables. See Section 7.2, “Database Backup Methods”.
Use of new features, new configuration options, or new configuration option values that are not supported by a previous release may cause downgrade errors or failures. Before downgrading, it is recommended that you reverse changes resulting from the use of new features and remove configuration settings that are not supported by the release you are downgrading to.
Check Section 2.11.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 downgrading. If such changes have resulted in an incompatibility between MySQL versions, downgrade the affected tables using the instructions in Section 2.11.4, “Rebuilding or Repairing Tables or Indexes”.
If you use XA transactions with InnoDB, run
XA
RECOVER before downgrading to check for uncommitted
XA transactions. If results are returned, either commit or
rollback the XA transactions by issuing an
XA
COMMIT or
XA
ROLLBACK statement.
In-place downgrades are supported for downgrades between GA status releases within the same release series. Before proceeding, review Before You Begin.
To perform an in-place downgrade:
Review the changes described in Section 2.11.2.1, “Changes Affecting Downgrades from MySQL 5.5” for steps to be performed before downgrading.
If you use InnoDB, configure MySQL to
perform a slow shutdown by setting
innodb_fast_shutdown to
0. For example:
mysql -u root -p --execute="SET GLOBAL innodb_fast_shutdown=0"
With a slow shutdown, InnoDB performs a
full purge and change buffer merge before shutting down, which
ensures that data files are fully prepared in case of file
format differences between releases.
Shut down the newer MySQL server. For example:
mysqladmin -u root -p shutdown
After the slow shutdown, remove the InnoDB
redo log files (the ib_logfile* files)
from the data directory to avoid
downgrade issues related to redo log file format changes that
may have occurred between releases.
rm ib_logfile*
Downgrade the MySQL binaries or packages in-place by replacing the newer binaries or packages with the older ones.
Start the older (downgraded) MySQL server, using the existing data directory. For example:
mysqld_safe --user=mysql --datadir=/path/to/existing-datadir
Run mysql_upgrade. For example:
mysql_upgrade -u root -p
Shut down and restart the MySQL server to ensure that any changes made to the system tables take effect. For example:
mysqladmin -u root -p shutdown
mysqld_safe --user=mysql --datadir=/path/to/existing-datadir
Logical downgrades are supported for downgrades between releases within the same release series and for downgrades to the previous release level. Only downgrades between General Availability (GA) status releases are supported. Before proceeding, review Before You Begin.
To perform a logical downgrade:
Review the changes described in Section 2.11.2.1, “Changes Affecting Downgrades from MySQL 5.5” for steps to be performed before downgrading.
Dump all databases. For example:
mysqldump -u root -p --add-drop-table --routines --events --all-databases --force > data-for-downgrade.sql
Shut down the newer MySQL server. For example:
mysqladmin -u root -p shutdown
Initialize an older MySQL instance, with a new data directory. For example:
scripts/mysql_install_db --user=mysql
Start the older MySQL server, using the new data directory. For example:
mysqld_safe --user=mysql --datadir=/path/to/new-datadir
Load the dump file into the older MySQL server. For example:
mysql -u root -p --force < data-for-upgrade.sql
Run mysql_upgrade. For example:
mysql_upgrade -u root -p
Shut down and restart the MySQL server to ensure that any changes made to the system tables take effect. For example:
mysqladmin -u root -p shutdown
mysqld_safe --user=mysql --datadir=/path/to/new-datadir
If you downgrade from one release series to another, there may be incompatibilities in table storage formats. In this case, use mysqldump to dump your tables before downgrading. After downgrading, reload the dump file using mysql or mysqlimport to re-create your tables. For examples, see Section 2.11.5, “Copying MySQL Databases to Another Machine”.
A typical symptom of a downward-incompatible table format change when you downgrade is that you cannot open tables. In that case, use the following procedure:
Stop the older MySQL server that you are downgrading to.
Restart the newer MySQL server you are downgrading from.
Dump any tables that were inaccessible to the older server by using mysqldump to create a dump file.
Stop the newer MySQL server and restart the older one.
Reload the dump file into the older server. Your tables should be accessible.